Aller au contenu

Photo

GraphicsProcessorMSH -- how to make it export data as full floats? [solved]


  • Veuillez vous connecter pour répondre
15 réponses à ce sujet

#1
tmp7704

tmp7704
  • Members
  • 11 156 messages
From poking around it appears  the GraphicsProcessorMSH included with the game Toolset and used to generate the .msh files automatically converts provided floating point data (the "Float4" streams) into half-floats (the Float16_4 type) during the export.

Most of the time this loss of precision isn't noticeable but when it comes to items like hairs which include part of the skull which is supposed to match seamlessly with character's face, the precision loss causes visible gaps to appear between the face and skull meshes. This is because the difference between original vertex coordinate and the one encoded as half-float can be as large as ~0.5mm

The default game meshes work around that by having their vertex position stream encoded as full floats (FLOAT4 data type)

Question: how can i force the GraphicsProcessorMSH to do the same thing i.e. export the "Position" stream in FLOAT4 format instead of FLOAT16_4 it does by default?

edit:

Turns out, the version of program located in tools/export_processors/ is different from the same program located in ResourceBuild/Processors/MSH/

the graphicsprocessorMSH located in ResourceBuild/ generates proper full floats data and as such is the one to use.

Modifié par tmp7704, 01 juillet 2010 - 05:05 .


#2
ChewyGumball

ChewyGumball
  • Members
  • 282 messages
Perhaps the optimize parameter for the mesh in the xml file does that? Other than that you might just have to rewrite the binary file.

#3
tmp7704

tmp7704
  • Members
  • 11 156 messages
Nope, i've tried that with optimize set to "none" and that didn't seem to change a thing. I'm hoping there is some actual, straightforward way to achieve that because i doubt BioWare guys would be doing it in such convoluted way when they made the tool in the first place, so were in position to just put that functionality in as part of the automated process.

The GraphicsProcessor apparently can be fed some option switches but i couldn't find any info on what switches these would actually be -- if you invoke the tool without parameters it will show "[options]" as part of its command line arguments.

#4
Eshme

Eshme
  • Members
  • 756 messages
mhh! Lets find this out

#5
Eshme

Eshme
  • Members
  • 756 messages
lol its the filename. If it has "ul_" "ulm_" "har_" in it it will be big floats. At least for what i tried

#6
tmp7704

tmp7704
  • Members
  • 11 156 messages
Ohh, that's odd -- all the hair i made have the "_har_" bit in them but i'm only getting the half-floats.

Could you post the exact command you put in the command line to make the meshes? Maybe i'm doing something wrong here...

i'm using the command format i got from tazpn's tool docs: GraphicsProcessorMSH.exe -platform pc mmdtogff filename.msh.xml

Modifié par tmp7704, 30 juin 2010 - 11:11 .


#7
ChewyGumball

ChewyGumball
  • Members
  • 282 messages
I believe its just a prefix, no underscore or anything else before.

#8
Eshme

Eshme
  • Members
  • 756 messages
This is the commandline for me

"**\\GraphicsProcessorMSH.exe" -platform pc mmdtogff %1



I have lost my examples of filenames, i will try to get them again and post.

#9
Eshme

Eshme
  • Members
  • 756 messages
df_boo_hvy_0.msh.xml = float16

df_har_hvy_0.msh.xml = float32

blablabla.msh.xml = float16

blablabla_ulm.msh.xml = float16

blablabla_ulm_.msh.xml = float32



and that doesnt work for you?

#10
tmp7704

tmp7704
  • Members
  • 11 156 messages

Eshme wrote...

df_boo_hvy_0.msh.xml = float16
df_har_hvy_0.msh.xml = float32
blablabla.msh.xml = float16
blablabla_ulm.msh.xml = float16
blablabla_ulm_.msh.xml = float32

and that doesnt work for you?

Nope Image IPB  You can see example here:

Image IPB

_USAGE 0 is the position data stream, _DATATYPE 16 is FLOAT16_4, for regular FLOAT4's that value is 3 instead.

For the reference, the relevant part of .msh.xml looks like this:

<?xml version="1.0" encoding="UTF-8"?>
<ModelMeshData Name="ef_har_hat4c_0.msh" Version="1">
 <MeshGroup Name="EF_HAR_HC1_HairM1" Optimize="none">
  <Data Semantic="POSITION" ElementCount="334" Type="Float4">
  <![CDATA[ 0.0261412 0.0525967 1.62462 0
etc
]]>
  </Data>

Is there anything wrong here? I have the optimize also set to "all" but it didn't make any difference.

#11
Eshme

Eshme
  • Members
  • 756 messages
I took the file "df_boo_hvy_0.msh.xml" from biowares file samples, that you can download from somewhere. Im getting datatype 3 when i rename it like i said. And the file content doesnt seem to matter its alright. Weird that it doesnt work on you

#12
Eshme

Eshme
  • Members
  • 756 messages
But it happens for anything i try, also with my exporter when i export as different name.

#13
tmp7704

tmp7704
  • Members
  • 11 156 messages
Aarrrgh! Mystery solved Image IPB
I was getting the half-floats even with the BioWare's own files, so i took a closer look at the graphicsprocessor.exe itself.

Turns out, the version of program located in tools/export_processors/ is different from the same program located in ResourceBuild/Processors/MSH/

the graphicsprocessorMSH located in ResourceBuild/ generates full floats, just like you describe it.

effin' toolset.... Image IPB

#14
-Semper-

-Semper-
  • Members
  • 2 259 messages
but just for the meshes with the appropriate name. isn't it also necessary for other connected meshes like arms and boots? the naked version shows no gaps.

now if i want to use an other mesh as the naked arm it sounds like there will be issues with the vertexes.

Modifié par -Semper-, 01 juillet 2010 - 05:16 .


#15
tmp7704

tmp7704
  • Members
  • 11 156 messages
For the other parts this isn't really necessary because:



#1 all these parts are getting half-float coordinates meaning as long as the vertices match in the 3d program, after export they'll be all quantized in the same manner, and their coordinates will still match (although may be very slightly off compared to their original position)



#2 the camera is usually much closer to the character's head in the dialogues etc than it is to the other body parts, making any gaps in the latter less noticeable



the gaps i was getting with the hair models were mostly the result of the face vertices having full precision coordinates while the part i was adding was lacking that. If the face mesh was also encoded with half-floats the coordinates would match, like in #1

#16
-Semper-

-Semper-
  • Members
  • 2 259 messages
k, understand it. that's why they all wear necklaces. worried about that because arms and legs fit without problems to the body^^