kev 3ds loaders setBounds

[Bombadil]

It looks like the old version 2.x of DeepExplorartion caused much trouble with .3ds, the newer version 3.x exports much better 3ds models, so Kev's importer is pretty happy at the moment (and so am I).

One thing though: light. I use one directional light source . I set it so it shines from the viewer (+Z) to the origin (ie in the minus z axis) by doing something like

1   2

DirectionalLight dirLight = new DirectionalLight(new Color3f(0.8f, 0.8f, 0.8f), new Vector3f(0, 0, -1)); mSceneBranchgroup.addChild(dirLight);

With my own created Shape3Ds and Nodes it works fine, but with the loaded 3ds the light is inverted - or their normals, or my normals...
Anybody else noticed such?

Btw I use Kev's importer from Sunday (?) but Xith3 is from the Xith3d.org site (January 20th or such).

[kevglass]

You might want to check you've got the latest loader, I inverted the normals for a bug that was reported, but it turned out to be wrong so I swapped them back again.

TBH, not sure which way round is correct, so let me know if the latest version of the loader is still wrong, if so I'll swap um over again

Kev

[Bombadil]

You might want to check you've got the latest loader, I inverted the normals for a bug that was reported, but it turned out to be wrong so I swapped them back again.

TBH, not sure which way round is correct, so let me know if the latest version of the loader is still wrong, if so I'll swap um over again :)

I use the newest version now. Unfortunately, the normals' direction of my imported 3ds models looks to be inverted in my case.
However since I'm no (Xith)3d expert I'm not 100% sure about it. Any more 3ds loader users please? Maybe Javacooldude has been correct with his first assumption some days ago that maybe the loader's normals are inverted?

Just for clarification: If you use a directional light source in your scene and say

1	new DirectionalLight(new Color3f(0.8f, 0.8f, 0.8f), new Vector3f(0, 0, -1));

Then all Xith3d Nodes/Shape3ds should be lit from the "front", because there's the +Z, and the -Z is "in the screen/monitor", like the light's vector(0, 0, -1) ? Is this correct?

I've inserted a control Shape3d: a polygon with a normal vector of (0, 0, +1). It's lit correctly from the "front". Whereas to see the imported 3d model lit, in the same scene, I've to turn around the camera to see it lit (then from its "back")...


PS: How could we help you in making the loader "transparency" aware and in the future "multi texturing" aware? :-)

Games published by our own members! Check 'em out!

[kevglass]

Grab the new version, normals are inverted. I trust your evaluation well enough...

The loader does now support transparency, multi-texturing is another matter..

However, since I've now given up on my latest project and am thinking about the next one I'll spend some time trying to work it out..

EDIT: Could someone send me a 3ds model with multitexturing on?

Kev

[Bombadil]

Grab the new version, normals are inverted. I trust your evaluation well enough...

Downloaded, started... and I don't see any difference - which is quite strange. :-) I think I've to re-check that tomorrow...

The loader does now support transparency,

That's great.
On a small transparent test tube which uses the RGBA PNG format, I can't get it to work, though.
The example (116 KB) is is here. (Zip archive. No free model, just for test purposes.)

However, since I've now given up on my latest project and am thinking about the next one I'll spend some time trying to work it out..

That's nice. I'll try to test the loader.

EDIT: Could someone send me a 3ds model with multitexturing on?

Currently I've got a Lightwave multitexture example but can't convert it to 3ds unfortunately (the converter breaks the two PNG multitexture files).

Anybody who uses native 3d Studio and could save a simple example please...?

[kevglass]

That's great.
On a small transparent test tube which uses the RGBA PNG format, I can't get it to work, though.
The example (116 KB) is is here. (Zip archive. No free model, just for test purposes.)

Although that model does have transparency chunks it appears that the actual transparency value is set to "0.0" which means its not transparency at all

Not sure if this is a bug if the model or in the loader? I do have an example that has transparency that works fine (kindly supplied by Ant).

Been reading the 3DS spec thats available, still can find any way that multi-texturing could be specified. Might just be the spec is well out of date.

Kev

[kevglass]

A ha, the PNG was meant to cause the transparency.. hmmm

Kev

[Bombadil]

A ha, the PNG was meant to cause the transparency.. hmmm :)

Yes, in this model the transparency is controlled by an alpha layer inside the PNG bitmap, so the bitmap actually is in 32 bpp format = RGBA.

Some graphic artists don't like this packing and do supply a RGB-bitmap plus an extra A-bitmap. I don't know if the 3ds format can hold such a thing (Lightwave on the other hand can).

[Bombadil]

Grab the new version, normals are inverted. I trust your evaluation well enough...

What I noticed: the imported model's polygons are double sided. Which shouldn't be I think, or at least DeepExploration says they're single sided.
Could this be the reason for my light irregularity?

You can easily examine this with one of your 3ds examples inside you loader's ZIP archive (the character, the jeep1, the cube).

If you move the camera to inside an imported model, you see the backsides of the polygons and they're lit correctly (but actually they shouldn't be visible at all, in case they're single sided).


Another question: do you add transformgroups to the model's "components" in way like William's ASE loader does? If so: how would the user adress these TGs?

[kevglass]

You want just make a list of things that need doing?  

- 2 vs 1 sided polys
- Transparency in textures
- Access to the named elements
- Multitexturing (this doesn't appear to be possible in the 3DS format)

Kev

Games published by our own members! Check 'em out!

[aNt]

bones and IK LOL - while yer there..

[kevglass]

Now, I didn't say I was going to do any thing.. I just suggested we should make a list

Kev

[Bombadil]

You want just make a list of things that need doing?  ;D

Yes. :-)

- 2 vs 1 sided polys

There's a bug probably in the current loader so that is makes the polygons double sided when they're single sided. :-)

- Transparency in textures

Very important indeed. :-)

- Access to the named elements

Yes, would be great. How do you do animation at the moment? On your page you mention "3DS Loader, now with animation (prototype)"

- Multitexturing (this doesn't appear to be possible in the 3DS format)

Ouch! If so, big disadvantage. :-(
Now I started to feel happy with the 3ds format and now it looks like we can't do multitextures with it... would be a big problem.

With all the issues on 3d formats and the difficulty with complete imports for Xith I wonder how we'll ever make it do write nice games with nice graphics?
Of course Xith3d is very young...
This "question" isn't target at you, Kev. :-)  It's a general "question".

[kevglass]

Sure, never.

Check the source that came with the loader you have.... look for normal.scale(-1).

Kev

[Bombadil]

Well, I re-checked the normal vector problem. For a test I reset the normals with Xith's in-built calculateFaceNormals() on the loaded xith-Group. This corrects the lightning. (Using PolygonAttributes to cull back facing polygon is nice, too :-)
Of course this is just for a test to spot the problem because all the smooth groups of the model are being destroyed and Xith's calculateFaceNormal doesn't do what com.sun.j3d.utils.geometry.NormalGenerator does.

I see your loader does have the same normal generator problem I've encountered in my basic Lightwave import.
This is how it should like like:
and

After loading the model with your loader in Xith it looks like this:


Is there a comprehensive NormalGenerator class for Xith?

[Bombadil]

Sure, never.
Check the source that came with the loader you have.... look for normal.scale(-1).

Yes, it's there. So I got the correct loader version...
I've to confess I am no good with 3d, no good with mathematics, and no good with looking at complex source codes from other people. :-(
This is why I bother you so many times in this thread. :-)

[kevglass]

Not a problem, the source is evil, problem is its based on the most complete loader I could find since we seemed to need something pdq.

If you could send examples of the problamatic models that'd be very useful. I'm currently going to be working on the transparency in textures issue.

Kev

[Bombadil]

Not a problem, the source is evil,

I see. ;-)

problem is its based on the most complete loader I could find since we seemed to need something pdq.

Oh yes, that's been a good idea because we really need such nice importers. :-)

I don't know why the JARs of the different loader versions fooled me (probably I've been too dumb). It looks like I've always used the normal-inverting loader version. Sorry for that. When I comment out your source line in Face.java:

1	//normal.scale(-1);

and compile the sources and use that loader JAR for my imports, the lightning is correct. Great. So I think it's OK to comment out it in your official version of the 3ds loader. Sorry for all the trouble.

If you could send examples of the problamatic models that'd be very useful. I'm currently going to be working on the transparency in textures issue.

That's great.

I think the problematic models usually are those where for some normals in one group you would have to double a few vertices in order to be able to create new normals (when the crease angle is > a certain angle, 89° for example.)
In your Character.3ds example of the loader it's fine because each part has an own group and no crease is visible/there.

I haven't solved this problem in my Lightwave importer. I don't know if there's some support for such in your loader base?

So I packed some examples. Usually the normal cease effect is better viewable with models without textures (strangly enough the colors of those texture-less models aren't correct.) Please find the Zip archive here. The Png snapshots show how they should look like.

Thanks for your efforts!

[Java Cool Dude]

After loading the model with your loader in Xith it looks like this:


Is there a comprehensive NormalGenerator class for Xith?

Yup the loader somehow screws parts of the model normals (those black spots have the normal set to NaN, NaN, NaN)...

[aNt]

<a href="http://www.topresultmate.com/xith3d/block.swf" target="_blank">http://www.topresultmate.com/xith3d/block.swf</a>

yer this is what i get at the moment

3ds file is here: http://www.topresultmate.com/xith3d/building09.3ds

[kevglass]

Anyone else want to jump in here?

Kev

[kevglass]

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

[Bombadil]

Anyone else want to jump in here?

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:
and

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:


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.

[Bombadil]

The DeepExploration has got an option in the .3ds export dialog namend: "Save smooth groups data"
The help says

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.

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

[kevglass]

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

[Bombadil]

Sounds well! :-)

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.

It should work...

1   2   3   4   5

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. :-(

[kevglass]

Nope, remembered that bit

Kev

[tom]

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.

[Bombadil]

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

[aNt]

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?