Need for a normal generator class

Engines, Libraries and Tools Xith3D Forums
#1

I think Xith really needs a kind of NormalGenerator class, comparable to com.sun.j3d.utils.geometry.NormalGenerator for example (sorry no URL because I couldn’t find the utils package Javadoc online).

Some time ago this has been discussed in the forum and I think Abies mentioned he did something like that. Is there any news on it? Did it find its way to the Xith core?

The reason I ask is we’re currently discussing features for Kevin’s nice “.3ds” Xith importer (.3ds is a binary export format of 3d Studio). Please have look at it http://www.java-gaming.org/cgi-bin/JGNetForums/YaBB.cgi?board=xith3d;action=display;num=1076588169;start=75#75

I think William mentioned that his “.ase” Xith importer (for the ASCII export of 3d Studio) can load the normals generated by the editor.
However not all 3d formats contain normal vectors, and some just contain them optionally. The Lightwave format doesn’t contain any normal vector data. Not sure about Maya.

So in many cases you’ve to generate normal vectors without “creases”. Also if you create your models at runtime.
The NormalGenerator task isn’t trivial for 3d and maths newbies like me. :slight_smile: If I am right Kevin takes a look at how it could be implemented in his 3ds importer at the moent.
Maybe we should join forces and produce shared source nails with heads - so everybody needing real normal vectors for his complex 3d models could use it.

What do you think about it?
(My question is especially aimed at mathematical gurus. :wink:

#2

I’ll just quickly clarify that it’s not technically “my” loader - David did all the initial work on it a while back and I’ve been developing it further more recently.

I agree it would be nice. I wounder if we can just port the actual com.sun.j3d.utils.geometry.NormalGenerator?

Here’s the source code which in fact David started porting but removed it due to the following reason: Removing the sun utility classes I ported because they depend on a dll in java3d

The license at least appears to be compatable.

As far as a quick glance could tell, I don’t think that the normal generator depends on the DLL but perhaps another class did?

I’m guessing that this import (from GeometryInfo.java) is the nasty one: import com.sun.j3d.internal.J3dUtilsI18N;. But I wounder if we need that class for the NormalGenerator? It would certainly be worth a look. It’s possible to checkout David’s original port so maybe we should try and get rid of that dependancy.

Here’s the javadoc if you were looking for it.

Will.

#3

[quote]I’ll just quickly clarify that it’s not technically “my” loader - David did all the initial work on it a while back and I’ve been developing it further more recently.
[/quote]
OK, then credits for this loader go to David and you. :slight_smile:

[quote]I agree it would be nice. I wounder if we can just port the actual com.sun.j3d.utils.geometry.NormalGenerator?
Here’s the source code which in fact David started porting but removed it due to the following reason: Removing the sun utility classes I ported because they depend on a dll in java3d
[/quote]
:frowning: Dependend on a DLL, oh dear… that would be bad.

[quote]As far as a quick glance could tell, I don’t think that the normal generator depends on the DLL but perhaps another class did?
I’m guessing that this import (from GeometryInfo.java) is the nasty one: import com.sun.j3d.internal.J3dUtilsI18N;. But I wounder if we need that class for the NormalGenerator? It would certainly be worth a look. It’s possible to checkout David’s original port so maybe we should try and get rid of that dependancy.
[/quote]
Keving took a look at J3d’s NormalGenerator too recently, and didn’t like the source AFAIK. :wink: I think his work on that topic goes ahead, too. Please have a look at what he wrote today at 11:39:37 in the 3ds loader thread (see URL above, please).

Kev, would that started port of David’s NormalGenerator be of any help to you?

#4

Afraid not, the current state of the 3ds loader is that the verticies are in a rather bespoke format.

Wasn’t so much I didn’t like the look of the source, just that it looked really really complicated.

I’m pretty much out of ideas on this topic! :frowning:

Kev

#5

but wont all the loaders start hitting this problem?

#6

[quote]but wont all the loaders start hitting this problem?
[/quote]
I think yes. At least for all loaders which can’t rely on exported normal vectors (as said, some model formats do optionally contain them, but others not).

We should solve it so that loaders as well as on-the-fly generated 3d-models (inside Xith) can use a kind of NormalGenerator (so it’s not part of a loader but part of Xith-core or -utils?).

Does Yuri work on a professional game with Xith3d and uses some internal and not ready yet Maya importer?
In case of that: Yuri, how do you handle the NormalGenerator problem?

PS: The day we’ve solved the NormalGenerator we can think about full support for animation, bones, of course multi-texturing, and some more. This isn’t trivial again, and I’ve to confess I’m pretty at a loss even with things like NormalGenerators… Sigh.

#7

My code support normal generation, with optional smoothing groups, but without support for crease angle. As an added benefit there is also cache-aware stripifier and few different geometry outputs.

So far it was not put into xith3d core - while I have tested it, it needs more eyes to spot problems (mostly contract wise, as implementation can be corrected incrementally if needed).

#8

[quote]My code support normal generation, with optional smoothing groups, but without support for crease angle. As an added benefit there is also cache-aware stripifier and few different geometry outputs.

So far it was not put into xith3d core - while I have tested it, it needs more eyes to spot problems (mostly contract wise, as implementation can be corrected incrementally if needed).
[/quote]
That sounds very well! Would you like to publish your code so we could use and test it?

Kevin: do you think you could test it with your 3ds loader, too?

#9

Any news on that topic? :slight_smile:

Another potential problem on that topic: for textured 3d models you’ve sometimes to double some vertex coordinates to create space for a new texture coordinate pair (in case the corners don’t share the same UV pair).
This will “break” the relation information which corners share the same normals, isn’t it?
OK, you could first call the normal generation and then caluculate the new texture vertex pairs, but even the normal generation extends the number of vertices in a manner you break the “texture to vertex number” relation, isn’t it?

How do you solve this?

#10

Any solutions on this topic?
I need a normal generator class too…
Would be perfect if s.o has a solution for that.

Bye

cw