[WIP] PIFT

[gap]

Originally Posted by Anvart

Are you the wrong (bad) opinions about the developers?
Import/export from/to obj-files by TDW's (or privateer's) program does not have any relation to developers.
I think.

So many game flaws and bugs were blamed to devs that I thought that one more would have passed unobserved.

@ gap,

E-Mail with new ObjSorter version sent.

[gap]

Originally Posted by privateer

@ gap,

E-Mail with new ObjSorter version sent.

Thanks privateer, trying it out

This version sets the usemtl line in the proper place now.
The G line still needs edited by hand but I'll get that adjusted in a bit I hope.
Doc's got me on some good drugs right now.

[gap]

Originally Posted by privateer

This version sets the usemtl line in the proper place now.
The G line still needs edited by hand but I'll get that adjusted in a bit I hope.
Doc's got me on some good drugs right now.

Sorry for the late reply privateer, had to go out. Testing the new version right away

[gap]

@ privateer

I followed your instructions: I prepared manually the mtl file for compatibility with MeshLab, filtered the model in MeshLab and re-exported it using the options you had recommended, I processed the obj file using your obj sorter v2, and last I added the subset names manually (I didn't re-edit the mtl file though).

This time GR2Editor v .374.1 didn't throw any error on importing the sorted object (used the file previously edited by Targor as GR2 template).

I was also surprised to see that now subsets are processed correctly.

Anyway, when I tried saving the file, I got the message that some chains were broken, and GR2E refused to go on with the saving.

I tried then with v 320.1 of TDW's program. This time no broken chain were reported, and yes, the newly generated file was much smaller than the old one

I opened the new file in GR2 E v .374.1, to check that nothing was corrupted, but no, the model was rendered correctly and no error was thrown on opening the file. I was about to report full success but at the last minute I decided having a look in the new file with Goblin, and this is how it looked:



Might it depend on the file that I imported the sorted meshes in, or on some other mistake on my part? Can you replicate my result?

I feel we are just a step from the ultimate solution

[gap]

Update:

I tried again importing the same sorted obj file as used in my previous attempt, but in a clean GR2 file (stock Iceberg01.GR2). This time GR2Editor v .374.1 didn't report any error on saving the file (so yes, something might be corrupted in Targor's file ), but the result seen in Goblin was exactly the same as before.

It's in the normals as done by Meshlab.

Imported with no normals and that effect is gone.
Doing some testing with Meshlab to see if the problem can be sorted out.

[gap]

Originally Posted by privateer

It's in the normals as done by Meshlab.

Imported with no normals and that effect is gone.

Yep, during my tests of yesterday, normals were checked; the one unchecked import option was AO map.

Might be unrelevant, but the Goblin render I have posted at post #66, reminds me of another screenie I took a while back:

http://www.subsim.com/radioroom/show...postcount=3847

That one was the result of importing the obj file exported by Targor in 3ds Max (which is the one working so far), but using costal_guns_small.GR2 or
ger_c3.GR2 -don't remember which one exactly- instead of Iceberg01.GR2, as base file for the importing.

Originally Posted by privateer

Doing some testing with Meshlab to see if the problem can be sorted out.

Looking forward to your news!

Figured it out in Meshlab.
Now I have to repeat it a few times to be sure I have the filters correct.
Here's the last import, with normals, useing Version 281_1
I use the Stuka as it's easy to view in game also.


File size is not changed much through different tests, so that's a big plus.
Another thing I did was do a new Alpha channel for the main texture when converting to DXT5 DDS format.
I copied the Blue channel to the Alpha channel but that still needs some work.

[gap]

Originally Posted by privateer

Figured it out in Meshlab.
Now I have to repeat it a few times to be sure I have the filters correct.
Here's the last import, with normals, useing Version 281_1
I use the Stuka as it's easy to view in game also.

much better

...but can you see that different UV regions have drastically different diffuse/reflection properties? It is as if each of them had its own material. I think I have never seen this before in Goblin

Yes, I see the regions getting the normals to cause that look is my guess at this point.
A coded smoothing effect maybe?


It's a step in the right direction anyway.

[gap]

Originally Posted by privateer

Yes, I see the regions getting the normals to cause that look is my guess at this point.
A coded smoothing effect maybe?

This is how Targor's obj looks in Goblin, seen from a similar perspective:

Originally Posted by privateer

It's a step in the right direction anyway.

Absolutely!

Here's a new Obj Sorter.
It now numbers the g object_ so you don't need to edit it.
https://www.mediafire.com/?lzcrdp7mlx59jjf

Checking the mesh I imported above, I see one of the Filters split some verts to cause the weird look.
The Normals are great, just not the splitting of verts causeing dual normals in the same position.

[gap]

Originally Posted by privateer

Here's a new Obj Sorter.
It now numbers the g object_ so you don't need to edit it.
https://www.mediafire.com/?lzcrdp7mlx59jjf

Gonna try it

Originally Posted by privateer

Checking the mesh I imported above, I see one of the Filters split some verts to cause the weird look.
The Normals are great, just not the splitting of verts causeing dual normals in the same position.

Yep, the vertex splitting seem to happen along the seams of different UV regions. Does the new version of your sorter fix the problem, or not yet?