It's not an essential, but it would be a nice bonus if they could be made to work, no pressure. ;)

Attached Link: Full size image of original scene

The attached image shows the scene as rendered by Poser at the top, and by LuxRender at the bottom. Ignoring the odd missing material which I can resolve myself, I am perplexed by the huge discrepancy between the two camera views. Neither image has been cropped at all.

While I'm happy to investigate this further myself, I also don't believe in reinventing the wheel. If anyone knows why the camera views should be so different, or can give me some pointers as to where I should start looking, it'd be appreciated.

Some information which might be useful to anyone willing to help:

Windows XP Pro x64 SR2
Poser Pro 2010 SR1
PoserLuxExporter_alpha_1-13a

Poser Main Camera used:
Focal: 24mm
focus_Distance: 206.4
fStop: 2.8
DollyZ: -93.12
DollyY: 6.858
DollyX: -1.886
zOrbit: 11
xOrbit: -29
yOrbit -13

The full size Poser image can be viewed in my Rendo gallery.

Edited: Nudity advisory added.

Some additional information:

LuxRender version: luxrender_CVS_250810_x64

Found in the Luxrender scene file:

start Poser camera "Main Camera"

LookAt -0.0620110183954 0.149866908789 0.132420003414 0.134735606876 -0.334942711458 -0.719783257294 -0.0788638485802 0.858550479707 -0.506627641549
Camera "perspective" "float fov" [55.5656650046]

end Poser camera "Main Camera"

Your camera coordinates mean nothing without knowing what your Poser display units are.

Meanwhile, I get a similarly messed up point of view, so it's not you.

Unfortunately I have to work and can't investigate it deeply. Perhaps odf or adp will have time.

Quote - Your camera coordinates mean nothing without knowing what your Poser display units are.

Meanwhile, I get a similarly messed up point of view, so it's not you.

Unfortunately I have to work and can't investigate it deeply. Perhaps odf or adp will have time.

Thank you BB. Poser display units are inches. I'll not worry over camera POV's until later in the project then.

Inches - really. I entered the values as inches as well, into my unfinished exporter, but I got slightly different numbers in the lookat and fov. Mine was wrong too, but in a different way. Very strange.

If it's any consolation to anyone, Reality users are having the exact same problem with their plugin.

Laurie

I switched to inches a while ago so that I could follow all of your tutorials :-)

Perhaps it's the rounding in the Poser display panel.
e.g.: DollyZ, which I quoted as -93.12, is actually -93.115921 when expanded.

Quote - If it's any consolation to anyone, Reality users are having the exact same problem with their plugin.

It shouldn't be a consolation to anyone. While I use Poser exclusively because I don't like DAZ Studio (most likely my problem rather than Studio's), I'd actually like to see users from both camps having no problems and getting great renders. It'd be so nice, wouldn't it, if everyone could be happy and having fun with these great tools, regardless of which camp they sit in? It's a shame this hobby has become so divisive, I think.

Oh, and just in case that came across the wrong way - I know you're not the sort to encourage divisiveness (quite the opposite, I've noticed). Rather, my comments are to the community in general.

Besides, if Reality didn't have any problems I'd be pleased, because it would give us more reason to be optimistic that there are solutions to be found to all problems as LuxPose is developed.

ok I did a test with Sketchup and the beta SU2LUX... no camera distortion. both views - SU and Lux - matched.

so. whats the common demonitator between DS and Poser cameras?

What I meant by that statement was, whatever the problems is (and it probably is a rounding error I'm told), then both programs suffer from it ;o). It's not native to just Poser or LuxPose ;o). How to defeat it is now a problem for the programmers I'm afraid ;o).

And yes, I'm trying very hard not to get into the Poser vs Daz argument. I don't care about DS, only Poser...lol. To each his own.

Laurie

Quote - ok I did a test with Sketchup and the beta SU2LUX... no camera distortion. both views - SU and Lux - matched.

so. whats the common demonitator between DS and Poser cameras?

Dizzi posted the reason a while back iirc.
LuxRender's field of view is determined by the shortest dimension while poser uses horizontal fov,  so currently you get the wrong view when width > height.

But I replicated the problem with a square aspect ratio, where neither side is shorter.

so whats he doing in the SU2LUX exporter then...

Does anyone know what unit of measure they're using in LuxRender to work things out? bagginsbill I know you're using Poser Inches but they may not match whatever LuxRender uses for inches. Just a thought.

ps I just noticed I'm using Feet & not Inches, hey I'm greedy. ;)

I think LuxRender uses meters, but I believe the programmers already know this. I'm using inches in Poser as well. I'll try changing it to meters, but somehow I don't think it's going to make a difference. I'll try it tho ;o).

Laurie

Errors:

Quote - workersPoserLuxExporter_workers.py", line 597, in write_sampler
print >> file, ' "integer initsamples" [%s]' % p.get("initsamples", 100000)
NameError: global name 'p' is not defined

should be gp.get instead of p.get

Quote - workersPoserLuxExporter_workers.py", line 195, in getImage
if node.Type() != poser.kNodeTypeCodeIMAGEMAP : return None
AttributeError: 'NoneType' object has no attribute 'Type'

 should be "if not node or node.Type() != poser.kNodeTypeCodeIMAGEMAP : return None" instead of "if node.Type() != poser.kNodeTypeCodeIMAGEMAP : return None

With those changes (and the "print "NORMALS",params.compute_normals" removed), my ibl without texture scene exports without error.

Perhaps there are other factors, but adding the aspect ratio to the fov calculation fixes the camera view issue for me.

Quote - Perhaps there are other factors, but adding the aspect ratio to the fov calculation fixes the camera view issue for me.

Exactly which line do we change to do that? Sorry...I know it's prolly been posted before ;o).

Laurie

Laurie:
open camexport.py and search for "fov = "
  change the part after the = so the line reads "

        fov = 360 / pi * atan(12.75 * min(1.0, float(params.resolutionY)/float(params.resolutionX)) / focal)

" (keep the spaces!)

open PoserLuxExporter.py:
find: "camparams = self.globalParameters.get("Camera", exdict())"
add after:

        camparams.resolutionX=resolutionX
        camparams.resolutionY=resolutionY

Thank you muchly ;o)

Laurie

Quick stupid question from me, Does the exporter actually export anything or does it just link to the items in the runtime?

The reason I'm asking is I have Poser installed on my Windows partition & Ubuntu doesn't have access to it directly, if I can move the exported files to a drive that Ubuntu does have access to & not need access to the Windows partition I can render in Ubuntu as well as Windows from the same files. Does that  make sense?

Quote - Quick stupid question from me, Does the exporter actually export anything or does it just link to the items in the runtime?

The geometry is exported, any textures used are just referred to by their path (meaning you'd have to copy those and fixup the paths).

Quote - Laurie:
open camexport.py and search for "fov = "
  change the part after the = so the line reads "

        fov = 360 / pi * atan(12.75 * min(1.0, float(params.resolutionY)/float(params.resolutionX)) / focal)

" (keep the spaces!)

open PoserLuxExporter.py:
find: "camparams = self.globalParameters.get("Camera", exdict())"
add after:

        camparams.resolutionX=resolutionX
        camparams.resolutionY=resolutionY

Which version of PoserLuxExporter.py does this code apply to?
The text string "camparams = self.globalParameters.get("Camera", exdict())" does not appear in my version (1-14b) and the only references similar to camparams are commented out and actually spelt cam_params.

Quote - > Quote - Quick stupid question from me, Does the exporter actually export anything or does it just link to the items in the runtime?

The geometry is exported, any textures used are just referred to by their path (meaning you'd have to copy those and fixup the paths).

However, I can make it an option to copy the textures to the target folder and then just use no path at all.

Or if the files can be reached, but via a different path prefix, I can add an option to just translate the paths.

Whichever you like, get it on the wishlist. I'm assuming that's in the wiki somewhere.

I'm really sorry I'm so busy with work and not making progress with these things at the moment.

Quote - Does anyone know what unit of measure they're using in LuxRender to work things out? bagginsbill I know you're using Poser Inches but they may not match whatever LuxRender uses for inches. Just a thought.

ps I just noticed I'm using Feet & not Inches, hey I'm greedy. ;)

Inside Poser, everything is in Poser Native Units (PNU). When you choose a Poser Display Unit (PDU) it is not changing the internal numbers. It is simply changing how those numbers are displayed in the Poser GUI. They're still in PNU inside.

The PDU conversion from PNU to inches is 103.200005 inches per PNU. There have been an extraordinary number of threads dealing with the fact that with this ratio, Daz figures are incredibly tall. However, the original ratio was 96 inches per PNU. Similarly, the current Poser metric ratio is 2.62128013 meters per PNU. Originally it was 2.4384 meters per PNU.

We're exporting Poser Native Units as is. For initial testing this has no impact. When we start to do displacement, it will. What this means is that the current PNU is passed to Lux as if it was 1 meter, instead of 2.6+ or 2.4+ meters.

So as soon as I can get out from underwater with work, I'll add the multiplier to convert Poser meters to Lux meters. It remains to be argued as to which of the two multipliers you want to use - the official current 2.6+ meters or the original 2.4+ meters.

I don't care either way. It's just a number I poke into the exporter. It could be a configurable parameter. The only reason it would matter is if you were trying to use assets (props, lights) that were made in something else, such as LuxBlend. If you wanted to mix and match stuff that isn't in the Poser scene with stuff that is in the Poser scene, you have to make a decision about how these things relate to each other, scalewise.

Personally, I like to compromise and assume that a Poser unit is 100 inches or 2.54 metres. Mostly because it's a nice round number to work with. :laugh:

gah! I'm lost - so many threads, I can't keep up... what's the deal with luxmatic? where's it at and all?

how many components is luxpose anyway, is it the one script/install/package?and where is that? lol

do i have to install luxrender separately? a "start here" step by step instructions would be nice...

help please! :)

The wiki page has a very clear step by step startup description: LuxPose Renderosity Wiki Page
Enjoy :)

ah, there's a wiki! cool, thanks, I'll start there! :)

Quote - > Quote -

open PoserLuxExporter.py:
find: "camparams = self.globalParameters.get("Camera", exdict())"
add after:

        camparams.resolutionX=resolutionX
        camparams.resolutionY=resolutionY

Which version of PoserLuxExporter.py does this code apply to? 

Sorry, it's in PoserLuxExporter_workers.py.

Quote - Sorry, it's in PoserLuxExporter_workers.py.

Thanks Dizzi. I've made the amendments now, but it seems to have made no difference at all :-(
The output from Luxrender remains just as it was before, bearing little relationship to the POV in Poser.

While I know Python, I don't know much Geometry so I'll leave this little matter to someone cleverer!

I'm in no rush to use Luxrender so I'll await further developments. I'm sure it'll all get sorted out in the end.

Snarlygribbly: I tried your camera settings in Poser Pro 2010 (inches as units and everything), but couldn't reproduce your problem at all. I tried versions 12 and 14b, since I'd just deleted 13a.

Very mysterious!

To provide a more usable test scene I have deleted all the objects from my original scene. The lights and cameras have been left just as they were. I have replaced the original objects with three Poser primitives for illustrative purposes. I understand it's ok to include them in publicly distributed scenes.

A zip file containing the scene will be attached in a follow up post(remove the .txt extension).

The Poser (top) and Lux (bottom) renders are shown above.

Windows XP Pro x64
Poser Pro 2010 SR1 (Units=inches)
Luxrender version CVS_250810_x64

Luxrender settings:
Kernel: Linear
Sensitivity: 50
Exposure: 1/250
FStop: f8
Default light group gain: 0.1

I agree that it would be useful to get to the bottom of this. I have to catch some sleep, but I'll look at your test scene tomorrow.

Since the field-of-view correction for viewports that are wider than high hasn't yet been incorporated into ADP's package, it would probably be best to only use square or portrait formats for these tests for now.

Quote - Let's assume it's something I'm doing wrong then. Still, it'd be useful to me and probably to others to work out what is wrong with my workflow.

To provide a more usable test scene I have deleted all the objects from my original scene. The lights and cameras have been left just as they were. I have replaced the original objects with three Poser primitives for illustrative purposes. I understand it's ok to include them in publicly distributed scenes.

A zip file containing the scene will be attached in a follow up post(remove the .txt extension).

The Poser (top) and Lux (bottom) renders are shown above.

I have the exact opposite problem. I didn't change my python settings however :o)

Laurie

when I went to render your test scene is there a reason you have it set to render at half instead of full? that could be part of the problem

i think it's your camera scale--you've got the poser cam scaled up to 200%+ & when i reset it to 100% it looks just like the luxrender.  so try changing that & see if that does it for ya.  interesting problem.

Quote - when I went to render your test scene is there a reason you have it set to render at half instead of full? that could be part of the problem

The problem originally manifested when I was rendering at full size. I just dropped it down to half to make it easier to post example images here. Full,half or quarter size makes no difference to the end result in Luxrender, so far as I can see.

Did you get the same results though? I'd be interested to know if this issue can be replicated on someone else's system.

I know full well someone's going to point out something obvious I've done wrong in a minute and that I'll feel like a fool, but hey, it might as well be me someone else :-)

Yes I got the same results as you

Quote - i think it's your camera scale--you've got the poser cam scaled up to 200%+ & when i reset it to 100% it looks just like the luxrender.  so try changing that & see if that does it for ya.  interesting problem.

Yay! Spot on - that's the problem solved.
I have no idea why the camera was rescaled - it's not something I've ever done consciously so was probably mentally blinded to the reading on that dial.

So it was me after all :-)
Huzzah!

honestly i'm surprised i saw it.  but so glad to help!

I didn't have that problem at all. All the alpha maps that I've used so far have shown proper shadows. But I haven't tried them in the newer versions of the plugin.

Edit: pokeydots - I can see some proper shadows that show the leaf outlines but not some others. Are you sure that all the maps transferred over?

Laurie

Is that tree fairly low-poly? Can you post some wireframes?

Checked the log file and all transmaps were there. I am going to try just the tree in a scene and see what happens.

Well, it's definitely not low poly ;o)

Laurie

lol :)  Well the tree byitself doesn't have problems so it must be something in the way the scene is set up