I haven't yet come up with the rotation calculation - was just testing camera position and fov.

Here's what I used.

def ExportCamera(scene, file):<br></br>
        import math<br></br>
        cam =
scene.CurrentCamera()<br></br>
        p =
cam.WorldDisplacement()<br></br>
        print >> file,
'LookAt %s %s %s %s %s %s 0 1 0' % (p[0], p[1], p[2], p[0], p[1],
p[2]-1)<br></br>
        focal =
cam.Parameter("Focal").Value()<br></br>
        fov = 360 / math.pi *
math.atan(12.75 / focal)<br></br>
        print >> file,
'Camera "perspective" "float fov" [%s]' %
fov<br></br>

I'm not overly fond of the convoluted way that adp has set up the exporter, with a class that saves a bunch of parameters in the constructor, then uses them in another function. This seems so much simpler.

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

(sorry, no email notification from RR)

I've updated the package. Without the transformation.

Grrrrrrr. I did half a million exports with C4D in the meantime and added the transformation I got to the Poser-Export file. No changes. Until I looked into the Log file - Lux was crashed from another error because of a typo I added manually. But the Lux-Userinterface was still alive, I could restart but Lux did not load new files ....

Still not correct is how the camera is exported. I see not the same as with Poser.

But the good news are: Anybody may download the package, unzip it and render exported Poser scenes. 

[http://www.poserprofis.de/PoserLuxExporter_Alpha

](http://www.poserprofis.de/PoserLuxExporter_Alpha)

Thanks for the correction, bagginsbill! I guess the Poser people really didn't like the metric system. :laugh: (I'm still suspecting it's actually 12.7, not 12.75, but we'll have to do really large renders to verify that)

I agree that for simple cases like lights or cameras it makes more sense to just use a function.

By the way: ADP had some code in the camera exporter that was supposed to take care of landscape vs. portrait formats. I may have removed that code a bit hastily, as I haven't actually tested whether Poser always uses the height of the render as the basis for its calculations, or the smaller side like C4D does. That should be easy to find out, but I'm at work right now, where I don't have access to Poser.

Poser uses the width, always.

And as for the 12.7 versus 12.75, I tested this with some extreme precision. I buit a procedural shader for my environment sphere that created little bars all around the equator. I had white bars every 10 degrees, green bars every degree, and black bars every 1/10th degree.

I then positioned my camera at 0 0 0 and rendered with dozens of focal lengths. This was how I arrived at 12.75.

If you compare the apparent fov from Poser with that of a 35mm SLR, Poser's focal length is just about a 1.414 crop factor, as far as I can tell to a precision of 4 digits. What I mean is, Poser at 100 mm looks like an SLR at 141.4 mm. My guess is that somebody did an extra sqrt somewhere that they should not have done.

I am building the camera roll pitch yaw right now. Will be done shortly.

I'll let you guys figure out the portrait/landscape problem.

By the way, in order to deal with that, the camera exporter needs information from the film exporter. And I suspect that the material exporter is going to need information about the world transformation should we decide to actually convert Poser units to meters so that other content can be combined with Poser content in Lux. (Unlikely, though) The material exporter deals in Poser inches for bump and displacement and the P node. (Firefly is entirely based on inches.)

Quote -
I'm not overly fond of the convoluted way that adp has set up the exporter, with a class that saves a bunch of parameters in the constructor, then uses them in another function. This seems so much simpler.

As I looked over my C4D exporter I saw a few hundred functions and classes. In a lot of files :)

I splitted the Python classes into Initialization, computingpart, outputpart. Just to have "complicated code simple". And to be able to "overload" parts of the classes. I couldn't know that a Poser-Exporter for Lux is easier than what you can find for other Applications (C4D, Maya, Blender).

I usually find that it's a better strategy to start with something simple like a single method and refactor it into several methods or a class if and when the need arises, rather than doing it the other way round.

Then again, I've been infected with the functional programming virus of late. I no longer believe in object orientation as the solution to all problems.

Well anyway, I finished the roll, pitch, yaw, fov calculation.

Poser render from a very dizzy angle using the face cam.

[Edit] Whoops - left a print 'yrot',drot in there from when I was making sure I passed in the right argument. Remove that.

I just tested in portrait mode and it works as is. There's no need to deal with which side is longer. Lux and Poser do it the same way - the fov is the horizontal width, always.

Go Team!
Go Team!

Hm. Pointing the spotlights is pretty easy. You ask for the light's WorldMatrix and then there's nothing to it.

Great work, bagginsbill! Thanks for that!

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

In mathematics you get the normal of a plane by mean of the vector product of two lines that belong to the plane. In case on a triangle you can get the normal by a vector product of two edges.
But this code looks a little different to a vector product, but it is.
The guys of CG invented a method that produce better normals for polygons. The result will be the same as the classic method if all the vertices of a polygon are in the same plane, but this is not always true. This method produce the average of the normals with less computation.
In case of a triangle, all the vertices always are on the same plane, so both methods give exactly the same result.

For a triangle ABC what this code does is;
N = ABxAC + BCxBA + CAxCB  removing all the terms that cancels itself.

Nice work guys.  Watching with anticipation :)

Yes, great work - from both of you!

Anything is ready for testing.

http://www.poserprofis.de/PoserLuxExporter_Alpha
 

Quote -
For a triangle ABC what this code does is;
N = ABxAC + BCxBA + CAxCB  removing all the terms that cancels itself.

Yes, thanks! I kind of knew that formula, which you might have guessed from the fact that I just implemented it. What I didn't know is how you got from there to the code you posted. I think I've figured it out now (and I'm happy to post the derivation later tonight if anyone's interested), but a reference would still be nice if you happen to have one.

On the way, I came to understand another formula for the face normal that I've seen floating around (and used in code because I got it from a trustworthy source; but now I've forgotten what that source was ) and could never quite make sense of. So that means I can probably shave of another Numeric operation from the code. I don't think I will use kawecki's version, since it looks a bit too convoluted for my meager Numeric skills.

Quote - > Quote -

For a triangle ABC what this code does is;
N = ABxAC + BCxBA + CAxCB  removing all the terms that cancels itself.

Yes, thanks! I kind of knew that formula, which you might have guessed from the fact that I just implemented it.

Oh, I just noticed that you were responding to bagginsbill, not me. Never mind, then!

Now this is getting silly. Thanks to the puzzler that kawecki gave me, I've been massaging the normal computation code even further, and this is the result:

    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>
           
start = p.Start()<br></br>
           
indices = sets[start : start + p.NumVertices()]<br></br><br></br>
           
p = num.take(verts, indices)<br></br>
           
q = rotate_rows(p, -1)<br></br>
           
n = num.sum(p * rotate_columns(q, -1) - q * rotate_columns(p,
-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(rotate_columns(normals, -1))<br></br>

What kawecki reminded me of is that instead of summing up over the cross products of consecutive edge vectors, one can just use consecutive vertex positions. I've never really understood why that worked, but now I do. Also, all the adding and normalizing doesn't care whether I have the columns in the wrong order (as long as they are all in the same wrong order, obviously), so I could simply pull the outer rotate_columns() call in the line that computes the cross product (hint: it's that really long one) out of the loop.

This also seems quite a bit faster than the previous version.

For completeness, here are the necessary imports and helper methods:

import Numeric as
num<br></br><br></br>
def rotate_rows(a, i):<br></br>
    indices = range(len(a))<br></br>
    return num.take(a, indices[-i:] +
indices[:-i])<br></br><br></br>
def rotate_columns(a, i):<br></br>
    indices = range(len(a[0]))<br></br>
    return num.take(a, indices[-i:] + indices[:-i],
1)<br></br><br></br>
def normalize_rows(a):<br></br>
    norms = num.sqrt(num.sum(num.transpose(a *
a)))<br></br>
    return a /
num.transpose([norms])<br></br>

Come to think of it, I might just as well inline those methods now, since rotate_columns() is the only one that's called more than once, and I always have three columns, anyway.

Quote - Oh, I just noticed that you were responding to bagginsbill, not me. Never mind, then!

I replied to both,  the question was the same.
This code (well something similar) I found long time ago and once understood how it works the only thing that I do is copy and paste, never touched it again.
There are other methods more complicated taking into account the weight of faces, don't know if are better or not, never experimented; Poser 6 use other method than Poser 4, depending the model sometimes with Poser6 looks better other time with Poser4.
I have a good collection of papers about CG and many never had read yet.
Search in yahoo or google and you will find a lot of pdf on different subjects to download, Wikipedia also has many things.

Hmm, does anyone have any experience with the return value of the UnimeshInfo() call in the Figure class? I thought it might have world coordinates for the welded figure, but then I find that it doesn't have world coordinates. Now I've looked at the structure closer and see that the unified geometry isn't even welded? What the...? That doesn't give me anything I can't get easily from the actor list for the figure.

Am I missing something?

Ah... actor.WeldGoals() to the rescue!

Amazing. Good contribution, kawecki.

And I'm glad odf is tackling the geometry - I wouldn't have done such a thorough job. I'm happy to stick to the shader analysis.

I wish my job gave me more free time. Sigh. Have to run.

odf, there should be something like geometry.worldvertex( i ) this should work. i had problems with the mass counterpart, but the single function seemed to work well.

yes, weldgoals gives the welding relationship.

Quote - odf, there should be something like geometry.worldvertex( i ) this should work. i had problems with the mass counterpart, but the single function seemed to work well.

Thanks! I'll keep that in mind for later. For what I'm trying right now, this does not help me, unfortunately.

But no worries, I'm working on the reconstruction of the welded mesh from the actor geometries and the welding information that Poser gives me. It's not too hard, but as you all know by now, I work slowly.

Ok, first off let me say wow....just wow, I'm amazed at how this is coming together.  I've been playing with the builds as they come out and having lots of fun, so thank you guys very much for this.

This maybe too early in the game (and I can always code it in by hand if needed) but have any of you thought of adding the lights as groups yet?  I experimented yesterday with adding each of my two lights as groups and added the sun group as well, and while I couldn't move the lights I could play with the intensity and even shut them off if I wanted all while rendering.

Just a thought/suggestion for future notice and no big deal since I can add it by hand, and thanks again for giving us another tool to have fun with!

The assembly of the mesh from the actors is coming along fairly well, but I'm still trying to understand some special cases and quirks. So that code (method make_unimesh()) doesn't do anything spectacular yet, just figuring out how the vertices for each actor need to be renumbered. It won't even get called at the moment, unless one adds that call to the ExportFigure class.

BB, of course I'm thorough with the geometry. I can't help it. Meshes and geometries are my thing. It's a matter of pride.

Quote - Ok, first off let me say wow....just wow, I'm amazed at how this is coming together.  I've been playing with the builds as they come out and having lots of fun, so thank you guys very much for this.

You're very welcome. If people are using it I'd be interested in feedback on the material conversion so far. If it isn't making the right guesses, suggestions for how to influence those guesses would be great. I'll make options and a GUI to edit them on a per-material, per-prop, per-figure basis.

Quote -
This maybe too early in the game (and I can always code it in by hand if needed) but have any of you thought of adding the lights as groups yet?  I experimented yesterday with adding each of my two lights as groups and added the sun group as well, and while I couldn't move the lights I could play with the intensity and even shut them off if I wanted all while rendering.

Just a thought/suggestion for future notice and no big deal since I can add it by hand, and thanks again for giving us another tool to have fun with!

Since I'll be working on the light exporter today, timing here is perfect.

We could go two ways. Or both.

1) Name the lights like this: GroupName:LightName. For example:
  Foyer:Spot1, Foyer:Spot2, Foyer:Spot3

Hall:Bulb

Living Room:Lamp1, LivingRoom:Lamp2

This would give you three groups to play with.

1. I make lists of lights in the export configuration file and provide a drag-and-drop GUI to create light groups regardless of name.

1+2) Groups are automatically created from the naming convention, but then can be joined/split through the export config tool.

Be aware that option 2 is a lot more work. It's more parameters to parse and more stuff in the GUI. Also, figuring out how to save that grouping info in the scene is tough.

On that subject, Poser is missing something that has bugged me for a long time. Perhaps I'm just not aware of it, but I can't find any simple way to encode arbitrary plug-in info into the scene or materials or props or figures. I'd love it if every object in a scene (and the scene itself) had a "metadata" property, in XML format. Then I'd be able to add extra info to anything that would be consulted by Python scripts.

My kludge solution for material metadata is that I rename nodes to give meaning. But that has severe limitations. (32 characters is one of them) But that is how I solved the problem of embedding info for VSS in a prop.

I've been thinking about some scheme involving the conversion of text strings into geometry. For example, suppose I made each letter of an "alphabet" be represented by a vertex. Then I can make text strings out of polygons.

Imagine a prop with 257 vertices (256 for ASCII, plus one extra value to indicate a 2-byte Unicode character or something like that).

Then the string "hello" would be a polygon with vertex indices 104, 101, 108, 108, 111.

I could jam that into a prop (one that is not visible). Poser would save it with the scene. A simple Python library would let you read and write these text strings in the prop.

Actually this is NumPy, not Numeric!  (Poser 7/8, PPro/PPro 2010)

Attached is a little script to output doc-strings from Posers Numeric as HTML.

Offical documentation for NumPy can be found here: http://docs.scipy.org/doc/

Using what NumPy can do with arrays may give another speed-boost? (question :) )

Seems to be an older version of NumPy. Offical documentation for NumPy 1.3 seems to fit what I see in Posers Numeric. 

@BB: Maybe using a (non-relational) database service to store XML-data for Poser could be a solution? (???)

A Poser-Database (something like "couchDB") could be usefull for other things too.

A script, once started, can be informed about each new actor loaded by Poser. At this point a decision can be made what happens with this actors materials. 

Quote - Since I'll be working on the light exporter today, timing here is perfect.

We could go two ways. Or both.

1) Name the lights like this: GroupName:LightName. For example:
 

Foyer:Spot1, Foyer:Spot2, Foyer:Spot3

Hall:Bulb

Living Room:Lamp1, LivingRoom:Lamp2

This would give you three groups to play with.

1. I make lists of lights in the export configuration file and provide a drag-and-drop GUI to create light groups regardless of name.

1+2) Groups are automatically created from the naming convention, but then can be joined/split through the export config tool.

Be aware that option 2 is a lot more work. It's more parameters to parse and more stuff in the GUI. Also, figuring out how to save that grouping info in the scene is tough.

Options...wow all I have been doing is going into the test.lxs and just naming the group after the light...

Quote -

start light "Light 1"

AttributeBegin
LightGroup "Light 1"
LightSource "spot"
"color L" [0.997 0.983 0.996 ]
"float gain" [921.600]
"point from" [-1.28401041 1.34252071 1.48603559 ]
"point to" [1.00000000 1.00000000 30.00000000 ]
"float coneangle" [70.000]
"float conedeltaangle" [70.000]
AttributeEnd

 
Which works fine for me (some may want a little more control over naming) so whatever is easiest to code for you in a convention you like is what I'll take

As for materials, the exporter (Baggins) posted is the one I used most recently and it choked on a scene (I expected it to, it was really big) but a one figure + backdrop came out just fine including the materials (backdrop was blown out, I'll play with it again to see if it was material or lighting).

@BB:

I tried a model based on V4 with these errors:

...
File "C:ProgrammeSmith MicroPoser ProRuntimePythonposerScriptsADPPOSERluxrenderworkersBBLuxMat.py", line 150, in eval2

  File "Z:poserpythonPOSERluxrenderluxmaticluxnodes.py", line 15, in emitMaterial

    i.emitLux(out, s, self)

  File "Z:poserpythonPOSERluxrenderluxmaticmatcore.py", line 234, in emitLux

    v.emitLux(preOut)

  File "Z:poserpythonPOSERluxrenderluxmaticmatcore.py", line 504, in emitLux

    self.emitLuxProperties(out, s)

  File "Z:poserpythonPOSERluxrenderluxmaticmatcore.py", line 513, in emitLuxProperties

    i.emitLux(out, s, self)

  File "Z:poserpythonPOSERluxrenderluxmaticmatcore.py", line 232, in emitLux

    v = toLuxColor(v, preOut)

  File "Z:poserpythonPOSERluxrenderluxmaticmatcore.py", line 45, in toLuxColor

    return v.luxColorCast(out)

  File "Z:poserpythonPOSERluxrenderluxmaticmatcore.py", line 530, in luxColorCast

    c.emitLux(out)

  File "Z:poserpythonPOSERluxrenderluxmaticmatcore.py", line 504, in emitLux

    self.emitLuxProperties(out, s)

  File "Z:poserpythonPOSERluxrenderluxmaticmatcore.py", line 513, in emitLuxProperties

    i.emitLux(out, s, self)

  File "Z:poserpythonPOSERluxrenderluxmaticmatcore.py", line 234, in emitLux

    v.emitLux(preOut)

  File "Z:poserpythonPOSERluxrenderluxmaticmatcore.py", line 504, in emitLux

    self.emitLuxProperties(out, s)

  File "Z:poserpythonPOSERluxrenderluxmaticmatcore.py", line 513, in emitLuxProperties

    i.emitLux(out, s, self)

  File "Z:poserpythonPOSERluxrenderluxmaticmatcore.py", line 234, in emitLux

    v.emitLux(preOut)

  File "Z:poserpythonPOSERluxrenderluxmaticmatcore.py", line 504, in emitLux

    self.emitLuxProperties(out, s)

  File "Z:poserpythonPOSERluxrenderluxmaticmatcore.py", line 513, in emitLuxProperties

    i.emitLux(out, s, self)

  File "Z:poserpythonPOSERluxrenderluxmaticmatcore.py", line 234, in emitLux

    v.emitLux(preOut)

  File "Z:poserpythonPOSERluxrenderluxmaticmatcore.py", line 503, in emitLux

    print >>s, 'Texture "%s" "%s" "%s"' % (name, vtype, self.LuxType)

AttributeError: 'Bias' object has no attribute 'LuxType'

adp,

Quote - 'Bias' object has no attribute 'LuxType'

I wrote the list of nodes currently understood. Bias is not one of them.

Anytime you get has no attribute 'LuxType' it means the MatConverter does not have a Lux implementation for this yet.

Bias cannot be done because Lux does not have a "pow" texture.There are other nodes in there that aren't supported. In order to convert one of these Alternate_Diffuse shaders (of which I produce a ton) I have to fully analyze it to figure out what it is trying to accomplish.

In this case, it is one of the fake SSS techniques: Diffuse->ColorRamp(low red to black). I will write a recognition algorithm for this type of shader and it will be dealt with, even if it cannot be literally implemented this way in Lux.

I first published this type of shader in 2006 and it got copied into Daz products and now is everywhere. (Although I don't use this tactic anymore.) I'll be sure to make it work.

Actually, it's kind of nice because it pretty much 100% tells the MatConverter "Here we are trying to do skin".

Quote -
I wrote the list of nodes currently understood. Bias is not one of them.

I know. But isn't it better to return a "default" material (and a warning) insteed of an error?

Maybe. I'll make that an option.

Right now I'm working on lights. Point lights in particular. I'm not going to convert them to Lux point lights. They don't work very well in an unbiased renderer. I'm converting them to glowing spheres. 

I optimized my standard "Poser-Proxy". 

Once started the script is able to control Poser-Python. If actors are added (even while loading a whole scene) each new actor is added to a global dictionary. And removed if required.

Additionally there is a (replaceable) scene.Idle() function. This function is called if Poser has nothing to do.

Standard event handling is also catched and can be controlled. No problem to have another script running. If a running script calls "scene.ClearEvents()" for the running scripts everything behaves as normal. My script is still running and receives events :)

The trick is done by overwriting "poser". Even:

del poser
import poser

returns the overwritten class (my script is simply untouched).

poser.Scene() returns another overwritten object. Both -poser and poser.Scene()- have the same functionality as normal. But both of them are standard Python objects now (extendable). A reference to the original (poser/poser.Scene()) is stored in the new object.

Maybe this is usable in some way to have a tight binding between Lux and Poser (geometries/materials/camera/lights). 

Oh - that's excellent adp. I too wrote a Poser server and can extend it very easily but didn't play nice with Poser 8. The idle callbacks in Poser 8 behave differently, and doing background activity and called processSomeEvents was very erratic. I replaced that with a wxTimer callback for Poser 8 and Pro 2010. It works well, but I never did the interception of poser.Scene() as your'e doing. Of course this is not necessary with wxPython now available.

How did you do it?

Quote - Maybe. I'll make that an option.

Right now I'm working on lights. Point lights in particular. I'm not going to convert them to Lux point lights. They don't work very well in an unbiased renderer. I'm converting them to glowing spheres. 

Wow! 

I saw Lux can use geometries as lightsources. But implementing this for Poser .... Wow!

Don't forget to implement the "sunlight" Lux supports (I'm sure you don't).
A lot of scenes do not need more :)

If you use actual point lights in lux, they have no physical size and cannot be seen by ray paths that go through refractive materials or bounce off perfect reflector materials like glass or mirror.

Over and over I read Lux advisors telling people not to use lights that have no physical dimensions.

So I use spheres for the point lights.

In Poser, we control the shadow blur radius through a parameter, but I found that the Python function to query this value always returns the value for the depth-mapped shadows, not the raytraced shadows. And point lights only have raytraced shadows so you cannot set the other value that gets returned.

So I decided to do something different. Poser lights have a "scale" dial. They make the preview object that represents the light bigger or smaller. For point lights, this is a little sphere. The scale has no affect on rendering in Poser, just preview.

So - how convenient. A dial that visually and numerically indicates the size of a sphere surrounding a point light. Perfect. I mapped that into the Lux emitter sphere radius.

Here's a snapshot of my preview window, showing two different point lights.

Observe the reflections and caustics on and under the glass ball.

You don't get those in Lux unless you use area lights.

Quote - So I decided to do something different. Poser lights have a "scale" dial. They make the preview object that represents the light bigger or smaller. For point lights, this is a little sphere. The scale has no affect on rendering in Poser, just preview.

This is a really great idea! 

The resulting Lux-render is ... no words for that.
Who thought Poser users can compete with professional flagships someday?

This method has some advantages compared with timers. 

With Lux you do not have to decide what color to make your lights in advance. These are actually white in the scene file. But in real time I adjust color and gain. Fantastic. No more rendering over again just because a light needs adjustment. This is outrageous actually. Probably the number 1 feature that Poser lacks.