3ds2kex - beta - bug report - doubled vertices of mapping regions; G4 crash events

[maxkop]

Hello KnifeEdge,

we have another problem with the 3ds2kex - beta - exporter. I've created several .blend, .sup, .kex, and .3ds - files to explain the problem to you. When you unpack the .G3X file (rename to .zip (ZIP files have a 100.00 KB limit in the forum)) you will find multiple files in there. Important are really the .kex - files.

sphere-3dsmax.KEX

sphere-3dsmax-ns.KEX

sphere-blender.KEX

sphere-blender-ns.KEX

sphere-3dsmax.KEX and sphere-blender.KEX are containing 2 sphere - objects called FUSELAGE and ~CS_LMW with different Smoothing - values applied on it.
The 3dsmax-file is holding in addition a point helper ~CS_GLOBALOPTIONS with NUP_MaxSmoothingErrorDEG=10 while ~CS_LMW is holding NUP_MaxSmoothingErrorDEG=2.

The same objects in sphere-blender.KEX are holding the same parameters in the .sup-file (NUP_MaxSmoothingErrorDEG=10 is applied on the RootFrame - Object - the only way it worked by me using 3ds2kex - beta)) NUP_MaxSmoothingAngle=2 is applied to the ~CS_LMW - sphere - object.

Time for the first questions:

Am I understanding that right?

NUP_MaxSmoothingErrorDEG is the global parameter for all objects in the .kex - file. G4.0 will generate hard edges between any object - faces below this angle and therefore can only be applied on the RootFrame - object - entry in the .sup - file.
We have to know that in order to be able to handle how property - values applied on a ~CS_GLOBALOPTIONS - Object in blender are referenced in the .sup - file.

NUP_SmoothingAngleDEG can only be applied on single objects if the value of NUP_MaxSmoothingErrorDEG leads to incorrect smoothing on one or more individual objects and can
only be smaller than NUP_MaxSmoothingErrorDEG?

Let's continue with our problem:

sphere-3dsmax.KEX is working like it should. Both sphere's of each file are identical mapped into different UV-regions. I've rendered an UV-Map out of 3dsmax as well as out of blender that you can see how I've mapped the blender - created - .KEX - files and the 3dsmax - created .KEX - files.
As you can see, our mapping problem (the vertices of an .3ds - file cannot have 2 different texture coordinates on different UV-regions as in 3dsmax) in combination with the in general different mapping between the blender - files and the 3dsmax - files is leading to a different outline of hard edges on the blender - created - .KEX - file compare to the 3dsmax - created - .KEX - file.

If you import now the two 3dsmax - .KEX - files you can load the both sphere's without problems. But if you import the blender - created - .KEX - files, only the sphere-blender-ns.KEX (no smoothing values applied) can be loaded by G4.0 successfully. You can also import sphere-blender.KEX, but if you click on 'OK' or 'Cancel' after import and "Creating DDS..." (You can even see the sphere's in the preview window) G4.0 directly crashes without any error message neither by G4.0 itself nor by the OS (winxp).

I've attached two screenshots of my Grumman G-44 to show you how the doubled vertices affecting the aircraft geometry. As you can see, the hard edges are directly following the UV-Mapping - Borders and the reflectivity calculations are broken on the edges.

I hope I was successfully able to explain our last 2 problems to you, before 3ds2kex is a real alternative in creating custom aircraft content.

Take as much time as you need to fix the problems. There's no hurry (probably it's only me who want's to model with blender )

Greets,

Max

 

[maxkop]

Hello KE,

It's now the 4th month after this bug report and I would like to know if something can be done concerning these problems with 3ds2kex (at least if the crash event can be fixed). Some feedback would be nice....

Greets,

Max

 

[maxkop]

Hello KnifeEdge,

are you out there?

Greets,

Max

 

[arb6591]

Max,

KE responses seem to follow some mysterious pattern .....
I can not understand why they ignore some posts ( That's the word that comes on my mind anyway)
You asked for the 3rd time , very nicely, how hard would be to answer in a fashion :'"Yes, we know about the problem and we are working on it but we can not predict when it is going to be fixed"

I can understand that the problem you presented might be not a major concern for KE but any kind of reply would be nice just to show some respect for the customers

Andrzej

 

[maxkop]

Hmmm. Don't want to stress anybody. But KE has added the blender export alternative with a small export tutorial to their KEMAX - Tutorial Webside, here. (Last Chapter on the bottom of the page). Firstly recognized it last week, so perhaps I have missed something.

They don't deeply explain what the script can do, especially how much time you can save now by exporting via blender instead of using gmax, MDL - Exporter of MSFS, Middleman and MDLcommander. The strange thing is, yes the blender export works, but when I export my Grumman G-44 from Blender to .kex I get so many hard edges, especially in regions of clear visiblity that it is really disturbing; and one cannot always map his opjects, in that way, the UV-Seams are running only on "wanted" hard edges.

So after seeing the new chapter, I thought they have fixed something in relation to this bug. But in fact, the script is useless if you have no control over what you are getting in Realflight.

I know, I know.....patience patience patience....

Greets,

Max

 

[rayvel]

Wanted to echo maxkop's comments in this thread. Technically the issue appears to be with the 3DS file format more than anything.

Since 3DS only supports a single UV-mapping coordinate per vertex, the script is forced to duplicate (copy) all verticies along UV-mapping seams.

When 3ds2kex.exe converts this 3DS file to KEX format these duplicated verticies cause a hard-seam in the output. Essentially 3ds2kex.exe should instead detect these duplicates and merge them back into a single vertex - or more specifically to recognize these verticies form part of a smooth surface.

See attached image for a simple sphere with each half UV-mapped to different portion of the texture file - notice the hard edge in the top right.