kev 3ds loaders setBounds

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


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).

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

Kev

[quote]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 :slight_smile:
[/quote]
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


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? :slight_smile:

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

[quote]Grab the new version, normals are inverted. I trust your evaluation well enough…
[/quote]
Downloaded, started… and I don’t see any difference - which is quite strange. :slight_smile: I think I’ve to re-check that tomorrow…

[quote]The loader does now support transparency,
[/quote]
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.)

[quote]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…
[/quote]
That’s nice. I’ll try to test the loader.

[quote]EDIT: Could someone send me a 3ds model with multitexturing on?
[/quote]
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…?

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

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

A ha, the PNG was meant to cause the transparency… hmmm :slight_smile:

Kev

[quote]A ha, the PNG was meant to cause the transparency… hmmm :slight_smile:
[/quote]
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).

[quote]Grab the new version, normals are inverted. I trust your evaluation well enough…
[/quote]
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?

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

  • 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

bones and IK :slight_smile: LOL - while yer there…

Now, I didn’t say I was going to do any thing… I just suggested we should make a list :slight_smile:

Kev

[quote]You want just make a list of things that need doing? ;D
[/quote]
Yes. :slight_smile:

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

Very important indeed. :slight_smile:

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

Ouch! If so, big disadvantage. :frowning:
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. :slight_smile: It’s a general “question”.

Sure, never.

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

Kev

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

http://mitglied.lycos.de/nautis/Publik/Normalen_Org.png
and
http://mitglied.lycos.de/nautis/Publik/Normalen_Orgdraht.png

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

http://mitglied.lycos.de/nautis/Publik/Normalen_Xith.png

Is there a comprehensive NormalGenerator class for Xith?

[quote]Sure, never.
Check the source that came with the loader you have… look for normal.scale(-1).
[/quote]
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. :frowning:
This is why I bother you so many times in this thread. :slight_smile:

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

[quote]Not a problem, the source is evil,
[/quote]
I see. :wink:

[quote]problem is its based on the most complete loader I could find since we seemed to need something pdq.
[/quote]
Oh yes, that’s been a good idea because we really need such nice importers. :slight_smile:

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:


//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.

[quote]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.
[/quote]
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!

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

http://www.topresultmate.com/xith3d/block.swf

yer this is what i get at the moment :frowning:

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