Anyone else want to jump in here?
Kev
New version uploaded,
- 2 Sided stuff fixed
- Transparency in textures should work too
- Added rudimentry support for named objects (untested). TDSModel.getNamedObject(String name)
Hope this helps more than it breaks. Not having much success with the normals stuff.
Kev
[quote]Anyone else want to jump in here?
[/quote]
Well, I can explain the effect of Ant’s example and my examples but not offer a programming solution. 
First I’ve to say you only see this effect with lights on. 
(The principle also applies to triangles.)
When the angle between two neighbour normal vectors n1 and n2 stay in a certain limit, let’s call it crease angle (like Java3D’s NormalGenerator does), you just avarage the 4 normal vectors (n1…n4) and set this value as the normal vector data for vertex P. So the shading of polygons n1…n4 at vertex P looks smooth.
However, if the crease angle exceeds 89° (or another fixed value) you can’t use the average normal data for both surfaces, but have two use two different normal vectors for the two surfaces at the same vertex. In fact you double the vertex coordinate data to have two different normal data.
For crease < 90° it looks like this:
http://mitglied.lycos.de/nautis/Publik/Smooth_Voll.png
and
http://mitglied.lycos.de/nautis/Publik/Smooth_Draht.png
However, if you say (to DeepExploration for example) to use a crease angle of >90° (in fact disabling the “smooth groups”), you get the effect we experience with the current version of the 3ds to Xith importer:
http://mitglied.lycos.de/nautis/Publik/Smooth_Aus.png
So I guess the current importer doesn’t do any doubling of normal vertex data to stop smoothing for > crease angles but always smoothens and it looks wrong.
Or maybe it does, but because it’s a tricky operation when a lot of triangles “meet” on a corner, the algorithm could be wrong. Or I could be wrong. 
PS: The reason you won’t see any creases in the Character.3ds example model of the loader zip archive is because it nicely uses own groups of surfaces at all the “hot spots” where the crease task would take effect otherwise.
The DeepExploration has got an option in the .3ds export dialog namend: “Save smooth groups data”
The help says [quote] If enabled (checked), then smoothing groups used by the triangles data are created and saved to the 3ds file.
If not enabled, then the objects appear faceted when rendered in 3ds or MAX.
[/quote]
So it looks like the 3ds format can optionally contain the normal vectors. But for models not containing this info the importer still needs to generate them. Am I right in assuming this?
For example the unfortunate Lightwave format doesn’t contain any normal vectors (or “smooth groups”). So any importer for .lwo/.lws has to generate the normals anways. Or when you generate the model at runtime…
I’ve started a “joined forces” thread on a potential NormalGenerator class here: http://www.java-gaming.org/cgi-bin/JGNetForums/YaBB.cgi?board=xith3d;action=display;num=1077185405;start=0
Well I tried to implement the normals stuff, at 2am this morning I gave up and reverted to the old stuff. Note sure what went wrong, this is what I tried to do:
- For each vertex index get the normal for the face.
- Attempt to add this normal to the record for this index
- If the normal being added is within the “crease” angle for all other normals that have been added to this record then just add it to the record.
- Otherwise try the next record for this vertex index
- If the normal can’t be added to any records because of the crease constraints, create a new record (and hence a new generated normal). Add the supplied normal to the new record.
- Once you’ve processed all the normals, process the list generating extra normals and updating a set of indices for normals.
It sounds complicated, but actually seemed right once I got down to it. Essentially you create smoothed normals like before unless the crease angle is breached, at that point you create a new normal.
The reason it might not have worked may be down to Vector3f.angle(Vector3f other). Not quite sure whether this works like I needed it to. Don’t think you can get an angle of greater than 90 degrees from it.
Kev
Sounds well!
[quote]The reason it might not have worked may be down to Vector3f.angle(Vector3f other). Not quite sure whether this works like I needed it to. Don’t think you can get an angle of greater than 90 degrees from it.
[/quote]
It should work…
Vector3d a = new Vector3d(0, 0, 1);
Vector3d b = new Vector3d(0, 0, -1);
double radiant = a.angle(b);
double degree = Math.toDegrees(radiant);
System.out.println("Angle is " + degree + "°");
Prints out 180°.
Did you omit the toDegrees() function? I sometimes forget about it.
Nope, remembered that bit
Kev
I like to think it is the shared edge between two faces that needs to be split. More difficult to implement as the edge info needs to be generated.
Artur has written something similar. Maybe we could test his code and one day it could be inside Xith then…?
http://www.java-gaming.org/cgi-bin/JGNetForums/YaBB.cgi?board=xith3d;action=display;num=1077185405
yer i think inside xith would be cool. i have now tryed loads of different setting in Max, Maya, PolyTrans with the same out come. the 3ds normals in xith are wrong. things look abit messy.
i take it this problem could also be messing with the shadow casting that now seem not to work?
kev as a side note… what about adding lights? just point and mybe amb lights? with animation that would rock …
Unlikely, the normals problem only occurs with smoothed groups, shadow casting can go wrong with any geometry (infact even hand coded geometry)
Added to “the list”. Feel free to hack the source
Kev
ok i got it looking nice again- i move over the maya and it seems to be coming out ok. i do get a little twinkly outline around the edge of the model mind u… but im putting this down to me seeing things for now :).
so everything seems to be of. smoothing can be done in maya so i dont need it later. im not saying a normal generator is not a needed- i think it is…
but so far so good…
[quote]so everything seems to be of. smoothing can be done in maya so i dont need it later. im not saying a normal generator is not a needed- i think it is…
[/quote]
So you tell Maya to export the generated normals, then you load the Maya export with PolyTrans and export it as .3ds file? And Kev’s loader is “normal vector” aware?
(William once mentioned he tells 3d Studio to export normals for the “.ase” format and David & his ase-loader loads these normals then.)
Still, we need a generic NormalGenerator.
well; make yer model in Maya- then before exporting (realy importent) delete the Mayas model history- i then use the PloyTrans-for-Maya plugin to save as 3ds.
kev i take me hat off to u for the cool transparence action! looks brilleant dude… [lights- oh go on, go on, go on, go on].
i have tryed prittly much everything in Max to get it to work- with no joy… i understand its abit mad having to use Maya and Polytrans to export a Max 3ds models… but hay- when where things simple… maybe theres a way of deleteing Max’s model history i dont no about?
oh kev- the model.nextframe(); will that loop the animation when it gets to the end?
[quote]well; make yer model in Maya- then before exporting (realy importent) delete the Mayas model history- i then use the PloyTrans-for-Maya plugin to save as 3ds.
[/quote]
OK thanks. Well, no Maya here, no 3d Studio, just a DeepExploration converter tool, which unfortunately doesn’t export the normals to the .3ds file (or I don’t know how to). If necessary, it generates them on the fly to display the model correctly, but the normals aren’t in the exported 3ds or at least not being loaded with Xith.
[quote]kev i take me hat off to u for the cool transparence action! looks brilleant dude…
[/quote]
Yes, transparency on the material/surface works fine now and looks so cool.
Problem 1) However I can’t get it to work with RGBA texture files (PNG). Kevin said it’s in the code and he sees my Tube.3ds transparent, but it doesn’t work for me. Would you (Ant, or Kev, or …) like to test my bundled Zip archive? Unpack and start the Testle.jar please. The xith.jar contains my used Xith3d/Jogl/3ds_loader version. You can move it and use your own Xith/Jogl/Loader version to see if that makes a difference.
I load the model via the InputStream constructor of Kev’s loader. It shouldn’t make any difference but who knows…
Problem 2) I still see the loaded models’ polygons being double faced. Kevins said the code removes the double surface but it doesn’t work here. Could you (Ant, Kev, …) please try to load the Tube.3ds model and move the camera inside the model to see if its polygons are single sided?
[quote][lights- oh go on, go on, go on, go on].
[/quote]
With lights you mean they should be loaded from the model?
If so, should be optionally though, because usually we load many models and set an own light or such.
Many thanks!
nop just solid here dude… not transparency on the texture Tube dude.
- lights: well its way simple to remove the globle lights from your model if u dont want any lights to be exported. just i think it would be top if u could have animating lighting working in xith just from making them in max, maya whatever :).
and with the new loader on kevs site i get:
java.lang.ArrayIndexOutOfBoundsException: 64 file: model/character.3ds
Wierd, I run with your xith.jar only and get:
http://www.cokeandcode.com/javagaming/tube.gif
Which looks transparent? Not quite sure whats going on here…
All materials are set to having CULL_BACK unless specified in the file as 2 sided.
Kev
That’s a bit crazy: Ant and me don’t see the transparency of the Tube, Kev does see it - with the very same application and xith/jogl/loader JAR ?
How can this be?
OpenGL problems?
humm strange. r u working with the newset cvs build kev. u seem to have a grey background- should be black