I question about vertex normals

#1 Yes, I'm almost sure
There is someting wrong in way the exporter managed normals.
I load a cube exported from Blender in "Torque ShowTool Pro" Demo.
Moving the light around the model the amount of diffuse color it seem not correct.

Can't some one confirm it ?

#2 I confirm the vertex normals are not handled correctly. Not sure if this and the fact the normal encoding function has been disabled has anything to do with it.

# Write normals and encoded normals
				# NOTE: removed encoded normals write
				if self.parent < 0:
					for u in self.normals:
						dstream.write8(0) # Skip enormals
					for n in self.normals:
						dstream.writePoint3F(n)

I am not sure exactly what the encoded normals are used for. I will have to dig around there. The poly normals appear to work fine as they draw fine.

Jameson

#3 Thank you Bennett for the answer !

Yes there's something wrong.

So I decided to use Mlkshape for exporting models.
I tried to export in .obj format from Blender then import in milkshape and re-export to .dts.
Seem it work.

Bye

#4 Little clarification after digging around a bit:

Seems torque does not use triangle normals but just vertex normals. The encoded normals appear to be a preprocessing step to reduce the size of the normal data, but I am not sure then why hold both in the .dts file structure.

I will need to take further discussion and questions into the private section, I'm sure.

#5 I was on the wrong track with the encoded normals. The problem is in the handling of the normal storing it in the list of normals.

A solution:
In Dts_Blender.py, search for this:

normal = matrix.passPoint(Vector(vert.no[0], vert.no[1], vert.no[2]))

and replace with this:

normal = Vector(vert.no[0], vert.no[1], vert.no[2])

This straightened me right up with normal data. My models now show properly in the show tool with correct lighting. This may fix your issues coding the shader and some other issues i've seen floating around the forums. This should be verified and added to the resource if possible.

Jameson

#6 Thank you !

#7 @Stefano:
Please let me know if this fixed your issue with the shader.
Thanks,
Jameson

#8 Jameson:

I added in that extra matrix calculation to attempt to fix a TSE bug someome was having with the vertex normals.
I am not absolutely certain if those normals accessible by script are in worldspace, or objectspace...

#9 I see. The mod i show above fixes my lighting in the show tool, exporting using the maxtrix.passpoint() fcn forces the normals y component to -1 (at least that's my read on it...didnt actuall dig into the binary or read values after the fcn call). I simply removed the call and it appeared to work properly. Seems blender is passing the normals in the correct space.
Thanks for looking at this,
Jameson

#10 The same normal issue has popped up on this [url="http://www.garagegames.com/mg/forums/result.thread.php?qt=25005"]thread[/url]. Thought i would link it here.

#11 I'm sorry to gravedig this post, but I find it astonishing that this bug is still present in version 0.91 although it has such a detrimental impact on the usability of the DTS exporter. In fact, whenever you have a mesh whose reference point has been translated from the origin, all the normals get messed up. This problem affect TGE users, I can't say about TSE user, because I don't have it and I can't access the thread reported in Jameson's post. The funny thing is that the fix proposed by Jameson has been introduced in v0.91, but incorrectly! In fact the guilty line (now moved from Dts_Blender.py to DtsMesh_Blender.py)

normal = matrix.passPoint(Vector(vert.no[0], vert.no[1], vert.no[2]))

was changed to

normal = Vector(vert.no[0], vert.no[1], vert.no[2])
normal = matrix.passPoint(Vector(vert.no[0], vert.no[1], vert.no[2]))

Status quo! However, I believe it was made it so because Jameson's fix was incorrect too. The correct fix (at least it solved all my problems with normals, I don't know if it can create ill-effects to somebody else) is as simple as the following:

normal = matrix.passVector(Vector(vert.no[0], vert.no[1], vert.no[2]))

Hope it helps.

#12 Ah, glad you revisited this! I have had great success with the exporter lately but had intermittant issues with the normals exporting. I did notice the fix I posted worked most but not all of the time but have had no real time to dig into it. I am greatful that you did... thanks!
I'm not sure who is the maintainer of the exporter, but they should definitely know this.

#13 Yup! For me (but I believe most indie developers are in my situation), costly tools like 3DS Max are not an option, especially when they have such a good free alternative like Blender. Given that TGE is oriented to the indies, I believe that having a good DTS exporter for Blender should be their top priority... V0.91 is quite good, in fact, but not as good as it could be and the presence of this kind of bugs is a clear clue that it doesn't get all the attention it deserves. But, of course, that's just my opinion ;)
To the maintainer: is the project page on blender.org a good place to post bugs/fixes/requests? Seems like a desert there...

#14 Use this same forum, the programers involved in the exporter will try to help you ASAP for sure.

#15 @Alberto:
Are you seeing normal problems under windows ? I've been trying to track this issue down for awhile, but was doing 90% of my work under linux. When I did some testing under windows, I seemed to be getting correct results, so recently I've been trying to talk to Ron Y about this as a linux issue.

Notably, under linux, even the Orc's normals aren't always good, but they seem to be fine under windows for me. Under linux, when I see problems with my blender exported models, I also see the same problems with the Orc.

I wonder if we're dealing with a video card/opengl issue here maybe ?

As far as getting help, I think Gustavo is correct. Joeseph is more or less lead on the exporter now. I've been mostly just doing testing and digging at a few things when I have time. James is pretty busy now with other stuff.

#16 @Todd, I was experiencing problems before the fix. Debugging into TGE about a strangely behaving mesh, I found the DTS contained normals with wrong values. In particular, the y and z coordinates seemed correct, but the x was always greater than 5 for every vertex! Of course, normalizing those "normals" would de facto make all normals pointing to the x direction. I immediately thought of some "translation" issue, as the mesh reference point was offset from the origin and moving it back to the origin resulted in the right normals.
As far as I understand, the passPoint() performs a full affine transformation (rotation/scale + translation), which is correct for points but not for vectors, while passVector() applies the rotation/scale part only, which is more correct for vectors. In fact, for normal vectors, even passVector() is not entirely correct, because it will produce the wrong result iff the transformation includes an anisotropic scale. Instead, the correct transformation would be the transpose of the inverse of the 3x3 rotation/scale submatrix (if you don't undestand what I'm saying, have a look at here). I didn't try this approach, yet, although it seems quite easy to do.
It is to be noticed that I currently use Blender only for static meshes. I am not aware of problems with animated meshes.

#17 ...

#18

Quote:As you can see, the normals on the first sphere are not right even within Blender. Blender then passes these incorrect normals to the exporter as they appear in the screenshot. Garbage in, garbage out. I can't think of any obvious way to 'fix' these normals on the exporter side.

The transpose of the inverse of the 3x3 submatrix should exactly correct that, as shown in the link I posted. In a certain sense, the normals are "correct" in Blender and that matrix is precisely the transformation needed to "fix" them. Well... that's the theory. I did not try it in practice. Could you please post your code?

#19 ...

#20 ...