wolf359 said: "Merely dumping/converting poser optimized models& textures into these other engines that use physically Correct lighting and different shading language will never get you the results you Desire IMHO."

And everyone can make that decision for themselves.

Besides, there's nothing any more wrong with making Lux better accept Poser content than it is to make any other content conform to Lux.

Laurie

Quote - The raytracing engine that I need must have:
1- Per face texturing (each face can have its own uv). Poser has
2- Per vertex color. (RGBA) Poser does not.

I've only been around Poser and Blender, may I ask what's vertex color for?

Quote -

I agree that Poser, like Daz, is what it is...especially in regards to using Poser/Daz content to render in other higher end apps.  But that doesn't mean each application doesn't have the potential to evolve. ......................
.............................
  if for no other reason than to show what the other guy is doing and thus provide the impetus for change.

I see no problem with Talented programmers
extending the capabilities of poser for the sake of improving poser itself.

Just look at what Philc has done
or the awesome poser physics plugin.
But it is interesting that in THIS THREAD
none of the poser Gurus showed any real interest in building a poser exporter to LUX from scratch.
and now that there will be a very nice one for DAZ we have this "Manhattan Project" style effort franticly undertaken in almost realtime in this forum.

yes competition is good for creativity!!!

at any rate it will interesting to see what poser exporter ,if any, finally evolves out of this.

Back to work

Cheers

Quote - But it is interesting that in THIS THREAD
none of the poser Gurus showed any real interest in building a poser exporter to LUX from scratch.
and now that there will be a very nice one for DAZ we have this "Manhattan Project" style effort franticly undertaken in almost realtime in this forum.

Funny how that works, innit?

Laurie

Wolf,

The exporter is NOT JUST for LUX.  If you were reading the threads, BB is going one-up on this idea and plans to make the base code flexible enough to allow adaptation and therefore export (in future iterations) to other renderers as well.  This is what Daz has done throughout much of its development cycle (taken existing ideas and tried to change/improve them).  It represents innovation and that SHOULD be encouraged without hesitation.

Cheers

Wow - so many provocative adjectives. What are you trying to accomplish, wolf? Are you trying to discourage what we're doing or what? 

I'm hardly "frantic" about an exporter to Lux. You mention no guru taking this on last fall. I thought about it, but as Poser 8 (and the new IDL) had just come out, and an SR was in the works, I had not yet been certain of how much Poser 8 was capable of (or not capable of). Further, at the time I had just begun work on Poser Pro 2010 and had no time to work on a Lux exporter.

That doesn't mean I had no interest - I simply had no time.

Nor does the activity you see now reflect any competitiveness or bias against DS or Reality.

It is simply this - Paolo said (more or less) in response to queries about a Lux exporter for Poser that he was not inclined to try, for a number of perfectly valid reasons. To him, exporter speed of 10 to 50 seconds is not acceptable, and upon querying SM about a C/C++ API, he was told that there isn't one. So - he didn't bother to make one. I do/did not classify this as a skill issue on his part, despite what he has said over at Daz. It was a business decision, based on his belief about the viability of a slow exporter, and the relative unlikelihood that goofy Poser shaders could be converted with any fidelity.

I was waiting for him to give his indication of interest or non-interest. Until then, I wasn't going to step on his toes. I thought it would be great if he did it. He may still do it, but for the short term, there won't be a Reality for Poser.

Meanwhile, I think it's a fun challenge, and there was a lot of interest expressed in have a Poser solution. Doesn't matter if Poser-Blender-Lux is also a solution - there is some non-zero demand for Poser-Lux and I'm at the point where I don't hold much hope of getting the kinds of effects I'd like to see in Firefly. And I'm curious about unbiased rendering, Lux is free, and much more powerful than it was a year or two ago. With the possibility of a GPU accelerated version of Lux coming (soon?) I'm even more interested.

And when I'm interested, I code. If you see a lot of progress it isn't at all that I'm frantic. Quite the opposite. If I was frantic and not busy with paid work, I'd be done already. Seriously. I'm sure there are faster coders than me somewhere, but I've never met one. Not even close. So the progress is because I'm good, not because I'm frantic. Take it down a notch, please.

Also, ADP and odf are good and I enjoy the cameraderie of a shared effort. So what if I could have already written the UV splitter. I'm in no hurry actually, and I think that the more people work on it, the better ideas will evolve. I do not have a monopoly on insight, and I prefer to work with others than work alone. Sometimes that really pays off, sometimes it doesn't. But in any case I'm having fun.

Fun is not a zero sum game. You should find no negativity to express just because I'm having fun.

If SM would let me at the Firefly code, I would not be doing anything with Lux.

:) why  let yourself get trolled by programming language discussions

one clever data structure or algorithm can make a difference of magnitudes...

one can do bad c++, one can do bad python, one can do bad java..

lets just wait and see

Sorry for my 2 day delay.  I had some private things to do (family).

Seems this goes to a very first class thing for Poser at the end :)

@ODF: Good work so far. Having a "pre-solution" is the right thing. 

@BB: Is it possible to have something able to import materials from Poser until the final solution is ready?

If additional Python libs (numpy?) can make things easier, the Python script below creates a registry-file (start from within Poser). If you activate this file (double click) any additional lib can be installed to be used with Poser Python (actually a few won't work because of some Poser-Python internals). 

With a little description ("how to use") anybody should be able to install required libs.

import os,sys
import poser

loc = os.path.dirname(poser.AppLocation()).replace("","")
version,rest = sys.version.split(None,1)
version=version[:3]


regfile = open("%sposerpython-%s.reg" % (loc,version),"w")

print  >> regfile, r"""Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINESOFTWAREPythonPythonCore%(version)s]

[HKEY_LOCAL_MACHINESOFTWAREPythonPythonCore%(version)sHelp]
@=""

[HKEY_LOCAL_MACHINESOFTWAREPythonPythonCore%(version)sHelpMain Python Documentation]
@=""

[HKEY_LOCAL_MACHINESOFTWAREPythonPythonCore%(version)sHelpPythonwin Reference]
@=""

[HKEY_LOCAL_MACHINESOFTWAREPythonPythonCore%(version)sInstallPath]
@="%(location)sRuntimePython"

[HKEY_LOCAL_MACHINESOFTWAREPythonPythonCore%(version)sInstallPathInstallGroup]
@="Python %(version)s"

[HKEY_LOCAL_MACHINESOFTWAREPythonPythonCore%(version)sModules]

[HKEY_LOCAL_MACHINESOFTWAREPythonPythonCore%(version)sPythonPath]
@="%(location)sRuntimePythonLib;%(location)sRuntimePythonDLLs;%(location)sRuntimePythonLiblib-tk"

""" % {"version":version,"location":loc}

regfile.close()

Quote - there are now visible seams on some actor boundaries. But I'll fix that last bit, and I'm pretty sure I can still peel a second or three off that computation time.

Maybe this has something to do with the scale factor Poser is using for geometries? If I import a Poser geometry in my C4D (via riptide) I have to use a factor of 800-1000).

In the meantime I've had a quick look into Lux-sourcecode. Seems that Lux analyses the geometry/normals and is using different strategies to triangulate and rebuilding normals. The sourcecode is indeed very well done (as BB said already). The important parts are easy to find.

Quote - I've only been around Poser and Blender, may I ask what's vertex color for?

Vertex color means that a model stores the color including alpha for each vertex.
Few format such as Stanford ply support this feature.
Ok, which is its use?. Well there are many uses.
For example if your model has a good polygon number you need no texture map at all, the color is stored in the vertices and the face pixel's color are interpolated from the face vertices color.
It render much faster, it look much better, no need for huge textures, no texture scaling artifacts
You only need to use some texture map only is some body parts that require more detail such as lips, eyes. To increase realism you can use procedural bumps.
Other application can be use the alpha information to make not so defined shapes such as ghosts.
Other use is to add ambient occlusion to a mesh and store this information as vertex color. Your model already comes with ambient occlusion and no needs to do it during the rendering.
Other use is to do radiosity for a scene and store the illumination in the vertex color of the objects.
If the nothing change position in the scene or little changes the scene is in thermodynamic equilibrium and so radiosity information doesn't change, so you can move your camera and make a real time movie with radiosity.

Thank you kawecki, very interesting.

Quote - > Quote - there are now visible seams on some actor boundaries. But I'll fix that last bit, and I'm pretty sure I can still peel a second or three off that computation time.

Maybe this has something to do with the scale factor Poser is using for geometries? If I import a Poser geometry in my C4D (via riptide) I have to use a factor of 800-1000).

No, I know why there are seams. See, I compute face normals first, and then for each vertex, I take the average of all the faces incident to it (more precisely, I take the sum of all those normals and normalize that). For a vertex that lies at an actor border, I do that averaging once from each side, so I get different normals. If I work with a fully welded geometry using Poser's unimesh method, I won't have that problem.

As for scaling: a Poser unit is meant to be close to 2.5 meters. A Lux unit, if I'm reading the documentation correctly, is 1 meter. So it would appear natural to scale by a factor of 2.5 when exporting to Lux. I'm not quite sure yet whether to apply that factor directly when writing out the coordinates or to add a transformation matrix for each object. I think in the long run it would probably be best to export geometries in (scaled) object coordinates instead of world coordinates and write out the world transformation as a matrix. That way, it will be easier for people to make small adjustments later in the .lxo files or use the exported content in scenes produced by other software.

@wolf359: I agree that 'to fix' was not a good word to use. From all I've seen, Luxrender is a fantastic piece of software, and a version 0.7 cannot be expected to be complete in every respect. From what I've picked up on various forums, BB and I are not the only ones who think that its handling of UV-mapped surfaces is not quite there yet.

And BB, I do not see how any of the things you said you'd add are exactly Poser-specific. Just do your thing, show them the textures you can produce, and don't mention Poser. :laugh: Don't show a Vickie or even Antonia render, show some patterned bowls, lamp shades, designer furniture etc.

PS: I'm actually not usually as frantic as my use icon may make it appear.

Quote - No, I know why there are seams. See, I compute face normals first, and then for each vertex, I take the average of all the faces incident to it (more precisely, I take the sum of all those normals and normalize that). For a vertex that lies at an actor border, I do that averaging once from each side, so I get different normals. If I work with a fully welded geometry using Poser's unimesh method, I won't have that problem.

You have to calculate the normals of the welded mesh and then export these normals and not the normals of the split mesh.

Quote - > Quote - No, I know why there are seams. See, I compute face normals first, and then for each vertex, I take the average of all the faces incident to it (more precisely, I take the sum of all those normals and normalize that). For a vertex that lies at an actor border, I do that averaging once from each side, so I get different normals. If I work with a fully welded geometry using Poser's unimesh method, I won't have that problem.

You have to calculate the normals of the welded mesh and then export these normals and not the normals of the split mesh.

That is exactly what I was trying to say. Thanks!

The problem of per vertex texture mapping can be solved by how you model and uv map the mesh.
The texture mapping is continuous even in closed meshes, I in general do it in this way and many times with different material boundary.

Quote - Nothing wrong with forking a code base if necessary.

Except when the fork is maintained by a single person: It means support will last as long as that person has time/interest in that project, which can range from several years to just a couple months.

Quote - As for my forking the Lux code, I expect that my desired changes will be rejected by the Lux architects:

While your arguments are valid (especially the second), I think there might be some collaboration possible.
As far as I understand it, Lux is still a pretty young project which hasn't yet stabilized (explaining the lack of some basic stuff). With some polite and diplomatic negotiation they might get interested by the dark side of the force. It's their baby, and they will certainly like the idea to see it expanded and enhanced, even if it is to cater for NVIATWAS renders. Why? Because the enhancements made to adapt it for Poser will profit to the "serious" users too, adding features which are missing so far.

Procedural textures are for making the opposite of NVIATWAS renders.

grin

Oooo, yuck! Wonderfully disgusting ;o).

Laurie

And let's not forget my avatar, which is also procedural.

I really should not have worked on this today, but I know you guys want a material exporter.

https://sites.google.com/site/bagginsbill/free-stuff/luxrender-exporter

In that page you'll find BBLuxExporter002.zip.

It is my complete exporter, using the WIP geometry exporter posted by odf and the earlier master script posted by adp, with some mods by me to get it to work.

It contains yaml source as well.

The big pile of new stuff is in the luxmatic subfolder. But nobody has to read that unless they are curious.

it supports:

Color maps
Bump maps
Transparency maps
Specular Maps
Clouds node (but not a good match)

AmbientOcclusion (yields 1, i.e. it is ignored)
Blender node
EdgeBlend node (but just uses the Inner_Color - EdgeBlend cannot be done in Lux yet)
Add node
Sub node
Mul node
Blinn node
PoserSurface built-in Diffuse node and Specular node

It will apply anti-GC to color maps, and I hope does not do that with any of the other maps.

When connecting things to anything but diffuse color, make sure it is black and white.

If you're using a Blinn node, anything the Blinn is connected to is ignored - i.e. I treat the node as the definitive and complete specification of the specular you want. Stuff can be plugged into the Blinn node, but results may be unpredictable at this point. A simple Blinn connected to Alternate_Specular works fine.

This is not a tweaked skin shader. It is just the basic Glossy shader with soft specular. I will do much better after I get all the basics working and figure out how to do a specific skin shader for Lux.

For the cornea, don't set transparency to 1 - that will make it invisible. Use transparency around .9 or .95 and boost the Specular_Value to 5 or 10, and be sure to use a very small highlight size.

Thanks, BB. Is there a succinct summary of how to use these files in your zip in order to get up and running?

Place the contents anywhere.

Load a scene. Start simple, with simple props and simple shaders.

I set up a Python button to run Luxport.py. You probably want to do the same.

Run it.

It will produce two files in the toLux subfolder. The scene geometry (and lights) are in test.lxs. The scene materials are in test.lxm.

Run LuxRender with the wrapper.lxs file - this calls on the other two.

I haven't kept up with any new camera or light exports (if any). So my output has to be manually adjusted for camera position. And all the lights point at 0 0 0, which is a bit of a pain.

The camera setup is in the wrapper.lxs file.

The first three numbers are the camera position, in PNU. The next three numbers indicate the coordinate where the camera is looking.

After that is a section for the "film" settings. It should be clear where the render width and height are.

Next is an Include of a Sampler. I provide two - SamplerDraft and SamplerFinal. The draft sampler does not do bounced light - it is like Poser 7. The final sampler does bounced light.

Until we have something more automatic, here's a handy way of getting fairly good matches between Poser and Lux for light and camera positions:

1) IMPORTANT: Measure everything in Poser using native units.
2) Use the dolly camera. I'm not sure yet how the other cameras work.
3) Use spotlights.
4) For all lights and the camera, add an invisible object to the scene to point them at.
5) Compute the field of view from the camera's Focal parameter as follows (like in the attached code):
    fov = 360.0 * math.atan(12.0 / focal) / math.pi

1. For each light, set the "from" parameter in Lux to the position of the light (in native Poser units; see above). Set the "to" parameter to the position of the object the light points at.
2. Set the first three arguments of the "LookAt" command to the position of the camera, and the next three to the position of the object the camera points at.

Obviously, this is not perfect. But we'll get there eventually. :laugh:

Thanks, both! whew!

Oh, you could just as easily use point lights, of course, if that works for you. Infinite lights seem to behave strangely in Lux, though. There must be something I'm missing.

Quote -
s. If I work with a fully welded geometry using Poser's unimesh method, I won't have that problem.

I see. Thanks. 

Today I'll going to grab all the code together to get a first beta-package.
Maybe a bit user-interface too. 

this is getting very close

Quote - > Quote - Nothing wrong with forking a code base if necessary.

Except when the fork is maintained by a single person: It means support will last as long as that person has time/interest in that project, which can range from several years to just a couple months.

This is not really a problem in reality.

This is kind of opensource. So, any other person is able to maintain the package. This is often done with other projects too.

What BB is planing to do is no big surgery. It's just a relative simple extension to have some maths with materials. The rest is done outside of Lux. So there is a good chance this extension will work with future versions of Lux. 

Only one more thing to do for the geometry export at this stage (I hope): unfortunately, the UnimeshInfo() call does not produce world coordinates for the unified figure mesh. That means we still have to grab the coordinates from the individual actors (a.k.a. "some assembly required"). We do get the topology, though (at least that is my understanding) and the mapping from each actor onto the mesh, so that should be easy as pie.

odf,

I have a question about the fov calculation:

fov = 360.0 * math.atan(12.0 / focal) / math.pi

I did some experiments in the past and may have done them incorrectly, but the factor I arrived at was 12.75, not 12. How did you arrive at the number 12?

That's a very good point, actually. The traditional 35mm film format is 24 x 36mm in dimensions. I was assuming Poser used that, and it fit well enough when I compared the outcome to Lux, which according to the documentation uses 32mm as the film height.

But: I saw a slight discrepancy that I couldn't quite explain. If instead of 24 x 36mm, the Poser programmers had used 1 x 1.5in, that would get us very close to the value you measured (half an inch is 12.7 millimeters). I'll check that tomorrow. Obviously, I could have done some more exhaustive measurements right away, but for today I was content getting an approximation.

Have you planned an infrastructure that makes finding and acquiring of community-made shaders easily? Will there maybe a central place where those are collected? One could tag a shader with certain keywords like for example the mat pose file name or sth. That could allow to have a client side script apply the proper shaders in a scene more easily.

I did not think about a Lux shader repository, but I do plan to support VSS-type Lux shaders that are templates and get filled in with textures in real time. This will allow you to switch texture sets while keeping the shaders intact.

This would allow people to use custom-made Lux textures that cannot be automatically produced from the Poser shader. For example, it's not likely that the material converter will always guess correctly that you want it to use the Lux specialized car-paint shader. I figured I'd throw a named node into the Poser material so next time you export it won't have to ask you again if its guess was OK. The problem with that is that loading a new texture mat-pose will wipe that marker node out. So I planned to also keep the same info in the exporter GUI. If a material does not have a marker, it will be recovered from the GUI memory. The only way you'd lose the markers is if you load a texture, do not export, and then save the scene and quit Poser.

If you do an export, the marker will be restored in the Poser material. Thus, saving the Poser scene (or a Poser material collection) will record your custom-Lux material mappings. Then reloading a material collection will automatically reload the Lux material as well.

There will probably be parameters to go with those Lux shaders as well, and I'll find a way to keep those in the Poser materials.

A classic way to calculate normals as Poser4 does, there are other ways to do it with different visual results.
The code is in C ( I use Begin for { and End for }).
I don't see any problem with speed for this, the only part that is worth to optimize is NormalizeVector that requires division and square root that is slow. I can be done in Assembler with SSE and it will be very fast..

6 seconds to export, 50 minutes to render. I totally don't care about the export time, given that this still has to render for another 9 hours or so before the artifacts go away.

Bring on the GPU rendering, Lux!

I put anything together but can't get an output Lux renders. Better: Nothing to see than black ...

Download from http://www.poserprofis.de/PoserLuxExporter_Alpha

Package contains anything one need. Unzip to your Poser Python directory (Runtime:Python:Poserscripts). There are two subfolders: Yaml (not used yet) und "worker" with the scripts from BB and ODF. To export a scene start the script named "PoserLuxExporter.py".

This script isn't usefull for anybody yet (you have to know how to handle Lux and correct some things manually). At least as long as camera and light isn't exported the right way, 

I'm now spending a bit time working on a user interface.

adp,

It would work a lot better if you didn't write a null transform. You reduced the entire universe into an infinitesimal point.

When I deleted the transform, it rendered an exported file just fine.

 I would like to apologize again for my sloppiness yesterday. I really, really hate it when people present their assumptions as facts, so I should bloody well not do it myself. I could play semantic games, but for all intents and purposes, the term "correct" implies precision, which I did not deliver.

The formula for computing the field of view (actually the angle of view, but Lux is going with the common misnomer) that I posted is correct, but the constant 12 in it was just a guess. I should have made that clear.

Quote - A classic way to calculate normals as Poser4 does, there are other ways to do it with different visual results.
The code is in C ( I use Begin for { and End for }).
I don't see any problem with speed for this, the only part that is worth to optimize is NormalizeVector that requires division and square root that is slow. I can be done in Assembler with SSE and it will be very fast..

Yep, that's almost precisely how I'm doing it, just vectorized via Numeric. Except that you're using a trick to save a few subtractions when computing the face normals that I had forgotten about.

Look:

    def
compute_normals(self):<br></br>
        verts = self.verts<br></br>
        polys =
self.geom.Polygons()<br></br>
        sets  =
self.geom.Sets()<br></br><br></br>
        normals =
num.zeros([self.nr_verts, 3], "double")<br></br><br></br>
        for i, p in
enumerate(polys):<br></br>
           
nv = p.NumVertices()<br></br>
           
start = p.Start()<br></br><br></br>
           
indices = sets[start : start + nv]<br></br><br></br>
           
points = num.take(verts, indices)<br></br>
           
s = points - num.take(verts, rotate_rows(indices, 1))<br></br>
           
t = rotate_rows(s, -1)<br></br>
           
n = rotate_rows(num.sum(s * rotate_columns(t, -1)<br></br>
                                   
- t * rotate_columns(s, -1)), -1)<br></br>
           
n = n / num.sqrt(num.dot(n, n))<br></br><br></br>
           
for v in indices:<br></br>
               
normals[v] += n<br></br><br></br>
        self.normals =
normalize_rows(normals)<br></br>

:laugh:

@kawecki:

Actually, on closer inspection, this bit in your code puzzles me:

   
            Begin<br></br>
           
      va = pol->vertex[j];<br></br>
           
      vb = ((j+1) == nv) ? pol->vertex[0] :
pol->vertex[j+1];<br></br>
           
      normal.x += (vertices[va].pos.y -
vertices[vb].pos.y) *<br></br>
           
           
          (vertices[va].pos.z +
vertices[vb].pos.z);<br></br>
           
      normal.y += (vertices[va].pos.z -
vertices[vb].pos.z) *<br></br>
           
           
          (vertices[va].pos.x +
vertices[vb].pos.x);<br></br>
           
      normal.z += (vertices[va].pos.x -
vertices[vb].pos.x) *<br></br>
           
           
          (vertices[va].pos.y +
vertices[vb].pos.y);<br></br>
           
    End<br></br>

Could you explain why this works or give me a reference?

Quote - > Quote - A classic way to calculate normals as Poser4 does, there are other ways to do it with different visual results.

The code is in C ( I use Begin for { and End for }).
I don't see any problem with speed for this, the only part that is worth to optimize is NormalizeVector that requires division and square root that is slow. I can be done in Assembler with SSE and it will be very fast..

Yep, that's almost precisely how I'm doing it, just vectorized via Numeric. Except that you're using a trick to save a few subtractions when computing the face normals that I had forgotten about.

Look:

    def
compute_normals(self):<br></br>
        verts = self.verts<br></br>
        polys =
self.geom.Polygons()<br></br>
        sets  =
self.geom.Sets()<br></br><br></br>
        normals =
num.zeros([self.nr_verts, 3], "double")<br></br><br></br>
        for i, p in
enumerate(polys):<br></br>
           
nv = p.NumVertices()<br></br>
           
start = p.Start()<br></br><br></br>
           
indices = sets[start : start + nv]<br></br><br></br>
           
points = num.take(verts, indices)<br></br>
           
s = points - num.take(verts, rotate_rows(indices, 1))<br></br>
           
t = rotate_rows(s, -1)<br></br>
           
n = rotate_rows(num.sum(s * rotate_columns(t, -1)<br></br>
                                   
- t * rotate_columns(s, -1)), -1)<br></br>
           
n = n / num.sqrt(num.dot(n, n))<br></br><br></br>
           
for v in indices:<br></br>
               
normals[v] += n<br></br><br></br>
        self.normals =
normalize_rows(normals)<br></br>

:laugh:

Slick. I figured the numeric library would make this fast and easy.

You may be reaching a point where the C calls you're making are a tiny fraction of the time and it takes a while just to find them.

By that I mean, for example, on each iteration of the loop, you're doing:

lookup "num" in globals 4 times
lookup (in num) "take" 2 times
lookup (in num) "sum"
lookup (in num) "dot"
lookup (in num) "sqrt"
lookup rotate_rows in globals 3 times
lookup rotate_columns in globals 2 times

That's 14 object lookups on each iteration. All of them are constants - they don't change.

So you can probably get another speedup by factoring those out before the loop into locals.

l_take = num.take
l_sum = num.sum
l_rotate_rows = rotate_rows

etc. and then just use them instead of doing all those lookups thousands and thousands of times.

Nice work.

Quote - @kawecki:

Actually, on closer inspection, this bit in your code puzzles me:

   
            Begin<br></br>
           
      va = pol->vertex[j];<br></br>
           
      vb = ((j+1) == nv) ? pol->vertex[0] :
pol->vertex[j+1];<br></br>
           
      normal.x += (vertices[va].pos.y -
vertices[vb].pos.y) *<br></br>
           
           
          (vertices[va].pos.z +
vertices[vb].pos.z);<br></br>
           
      normal.y += (vertices[va].pos.z -
vertices[vb].pos.z) *<br></br>
           
           
          (vertices[va].pos.x +
vertices[vb].pos.x);<br></br>
           
      normal.z += (vertices[va].pos.x -
vertices[vb].pos.x) *<br></br>
           
           
          (vertices[va].pos.y +
vertices[vb].pos.y);<br></br>
           
    End<br></br>

Could you explain why this works or give me a reference?

This looks like an attempt to do cross product, but the second terms all have + instead of -.

I don't get it.

Quote - > Quote - > Quote - A classic way to calculate normals as Poser4 does, there are other ways to do it with different visual results.

The code is in C ( I use Begin for { and End for }).
I don't see any problem with speed for this, the only part that is worth to optimize is NormalizeVector that requires division and square root that is slow. I can be done in Assembler with SSE and it will be very fast..

Yep, that's almost precisely how I'm doing it, just vectorized via Numeric. Except that you're using a trick to save a few subtractions when computing the face normals that I had forgotten about.

Look:

    def
compute_normals(self):<br></br>
        verts = self.verts<br></br>
        polys =
self.geom.Polygons()<br></br>
        sets  =
self.geom.Sets()<br></br><br></br>
        normals =
num.zeros([self.nr_verts, 3], "double")<br></br><br></br>
        for i, p in
enumerate(polys):<br></br>
           
nv = p.NumVertices()<br></br>
           
start = p.Start()<br></br><br></br>
           
indices = sets[start : start + nv]<br></br><br></br>
           
points = num.take(verts, indices)<br></br>
           
s = points - num.take(verts, rotate_rows(indices, 1))<br></br>
           
t = rotate_rows(s, -1)<br></br>
           
n = rotate_rows(num.sum(s * rotate_columns(t, -1)<br></br>
                                   
- t * rotate_columns(s, -1)), -1)<br></br>
           
n = n / num.sqrt(num.dot(n, n))<br></br><br></br>
           
for v in indices:<br></br>
               
normals[v] += n<br></br><br></br>
        self.normals =
normalize_rows(normals)<br></br>

:laugh:

Slick. I figured the numeric library would make this fast and easy.

You may be reaching a point where the C calls you're making are a tiny fraction of the time and it takes a while just to find them.

By that I mean, for example, on each iteration of the loop, you're doing:

lookup "num" in globals 4 times
lookup (in num) "take" 2 times
lookup (in num) "sum"
lookup (in num) "dot"
lookup (in num) "sqrt"
lookup rotate_rows in globals 3 times
lookup rotate_columns in globals 2 times

That's 14 object lookups on each iteration. All of them are constants - they don't change.

So you can probably get another speedup by factoring those out before the loop into locals.

l_take = num.take
l_sum = num.sum
l_rotate_rows = rotate_rows

etc. and then just use them instead of doing all those lookups thousands and thousands of times.

Nice work.

Thanks! I'll try your suggestion, but honestly, I'm not overly optimistic about it. In all the years I've been programming in Python, I don't recall ever having gained a significant speed-up from that kind of optimization, not even in inner loops that were executed tens of thousands of times like here. Your mileage may vary, of course.

But I've noticed that I'm doing

           
points = num.take(verts, indices)<br></br>
           
s = points - num.take(verts, rotate_rows(indices, 1))<br></br><br></br>

which should be equivalent to
<br></br>             points = num.take(verts, indices)
            s = points - rotate_rows(points, 1))

I did a test. I used the main camera, unorbited. This is the Poser render.