OctaneRender® for Poser beta - build 1.00p [OBSOLETE] Tweet

[face_off]

the main reason was that the exporter i used didn't convert well the mesh normals when exporting in OBJ format ( specially with the lightwave 10 exporter ).
Fixing (unifying) or flipping manually normals resolved this problem because when you unckek the smoothing parameter, you will give faceted output of your object ( of course with a plane it is not a problem...)

Hi Vincent. I'm pretty sure Poser is handling the normals correctly - however there are only 2 polys, so with smoothing on, Octane is treating the plane as a sphere (and having the 2 normals opposing). If the prop had 4 polys, Octane would treat the normal directions correctly even with smoothing ON. I notice with Octane release 1.01 there are some enhancements to mesh loading to allow the edge angle to be specified, so that may allow the plugin to better handle Ericks situation.

A multiple selection of meshes would be nice to have (for instance to remove bump maps from part the scene)
Another useful thing to remove bump maps from other objects with the same material name.

Hi Wim. The first point is tricky, since Poser itself doesn't allow multiple mesh selections. The second point would be doable - it may be better to implement this function in the Texture Compress script - I will investigate.

with 1.00p, I get lots of errors like "Polygon (xx) has not enough vertices" or "mismatch between vertices and textures".
If I export the scenes to .obj (i.e. the old, non-plugin-way) and load them into Octane directly, I have no issues.
For one scene I think it worked with an earlier version of the plugin (not sure though, I didn't track that precisely).

Hi Michael. The prop you are trying to load most probably has some polygons with 2 vertices. Whilst this is not strictly an invalid mesh, I found loading these into the Octane engine was causing issues that could lead to a crash further down the track. Check cuda.log to see if Octane rejected the mesh. Check octaneplugin.log - and the last "DEBUG:root:transferring actor [actorname] geometry to octane" will be the offending prop. My plan for the next release of the plugin is to filter out all 2 vertex polygons (since they do not render anyway) - I just need to ensure it does not lead to other issues.

Paul

[Zay]

Hi Vincent. I'm pretty sure Poser is handling the normals correctly

Poser hasn't handled geometry importing and exporting correct for years. I've sent mails to Smith Micro years ago and I was treated like a baby and I could hear from their answers that it was a problem in my end and not theirs. Funny that all props and figures has the same errors then.

Here's a simple box made in Modo 601. Looks fine loading it into octane standalone. Now try to load it in Poser and use the plugin and after that, export the box as OBJ and load it into Octane standalone. That will tell you one of the problems with the geometry import/export in Poser.
But it's old news and I know other vendors has also pointed it out to Smith Micro. But nothing has been done.

box.zip

(575 Bytes) Downloaded 237 times

[face_off]

Hi Zay

This is deep and complex topic In general, I've got the "what is a valid mesh" criteria pretty tight at the moment to keep the plugin robust. So the plugin will not load meshes with 2 vertex polys, etc. You would be amazed at the range of different topographies of meshes available for Poser - some are partially UV mapped, others have unused vertices everywhere. However Poser will load them. And as you say, you can load an "less-valid" mesh, export it from Poser, re-import it, and it cleanses it. Otoy has gone to a lot of effort to make the Octane Standalone OBJ importer robust, so it's very good at loading "less-valid" meshes. Keep feeding me meshes that won't load into the plugin, and I'll keep enhancing the Posermesh-to-Octane code to cope with it.

Paul

[vipvip]

Hi everybody

to be just 'concrete', i have to say that OBJ exporter works well between Poser and Maya (6.0) / Lightwave (11.03), as far as i tried of course ( but my works with transparent glasses and bottles are generaly efficient to detect normals problems, because of transparency and 2 sided view ).

For blender, I experimented some problems, particulary with octane-poser plugin as i already said to you, Paul, but with the following export-settings ( see attached) for blender seems to avoid them...

Paul, i had just a little question: do you gather i would be possible in the future to have the ability to keyframe over time the internal plugin values ( to make vary light-emitter intensity or animate textures... ) ?

Regards

Vincent

PS: i saw you 1.01 lens flare test ,with grass instance: nice
ps2: when i was talking about normal, i wanted to talk about the Obj-modeling-process on external apps ( with normal checking, correction/unify, double-point-removal if needed) but not of the poser interpretation, which is, as far as today, seems to be correct for me, APPART 1 THING: the pivot point ( origin ) bewtween these apps and poser IS NOT respected ( with all import-options desactivated in poser ) : it is ennoying for rotating meshes

[face_off]

Paul, i had just a little question: do you gather i would be possible in the future to have the ability to keyframe over time the internal plugin values ( to make vary light-emitter intensity or animate textures... ) ?

You can already animate light emitter intensities Vincent. There is a checkbox on the animation page for it - check the manual for specifics. Animation of textures is doable, but not in there at the moment. I've never seen a concise spec for how textures would be animated, so it's hard to know how people would be using such a feature.

ps2: when i was talking about normal, i wanted to talk about the Obj-modeling-process on external apps ( with normal checking, correction/unify, double-point-removal if needed) but not of the poser interpretation, which is, as far as today, seems to be correct for me, APPART 1 THING: the pivot point ( origin ) bewtween these apps and poser IS NOT respected ( with all import-options desactivated in poser ) : it is ennoying for rotating meshes

I've personally found Poser to be OK importing OBJ's a respecting the mesh origin from the OBJ. Are you exporting "world coordinates" from the modelling app? Poser simply loads the OBJ around the 0,0,0 point - so that is the origin, and the rotation point. If you move your model in the modelling app so that it's position with the rotation point at 0,0 ,0 is should load into Poser OK.

Paul

[vipvip]

Hi Paul

the 0,0,0 point is the theorical pivot point i use in the extern. app but most of the time the imported-obj has his pivot centered in the middle of the mesh in Poser ( with all import options disabled): i succeed in having the right position 1 ou 2 times,( i think it was with LWO export or DAE, i don't remember, but i would prefer to stay with obj, for inter-changing datas between apps ). As example, imagine a wine glass ( a pretty original idea ), i want the pivot point at the base and not at the middle of the glass: here is the problem i encounter because when modeling, the 000 point is at the centered-base of the glass ( which is the correct intention ).
I've further test to do... more wine-pictures to render for completing your facebook-wine-shop

For animating the light intensity, it is a miss, sorry, and i go straight head to have a look to this !

Animating textures would be very usefull for lighning effects, water displacement, and so on ( another great feature would be animated image sequences but i'm afraid it is not possible because of octane limitation )

thanks, as usual, for you attention

Vincent

[face_off]

i want the pivot point at the base and not at the middle of the glass: here is the problem i encounter because when modeling, the 000 point is at the centered-base of the glass ( which is the correct intention )

For my limited experience with this, you'll need to move the wine glass in the modelling app (once it's modelled) so the base of the glass is at 0,0,0, and then export and import into Poser.

Animating textures would be very usefull for lighning effects, water displacement, and so on ( another great feature would be animated image sequences but i'm afraid it is not possible because of octane limitation )

I agree - animated textures would be great. I'm just not sure how you would set them up. For water, you would need a separate image texture for every frame of the animation. Creating those image files would not be trivial (and would be outside the scope of the plugin). Once you had the textures (named water001, water002....water100 for the first 100 frames), I could setup the image loading dialog of the plugin so you tick the texture as "animated", and you would select water001. When rendering the animation, each new frame would load the texturemap for that frame for any "animated" image node. So it's doable, but a lot of work for the animator to setup. Would anyone use this feature?

Paul

[vipvip]

"so the base of the glass is at 0,0,0, and then export and import into Pose" -> that is what i do: i've to check again, it seems depend of the app for export...
Your automated integration seems to be good, like the one choosed for the blender cycles renderer: if it is not so much work on your side, it would be great to have it integrated !
Thanks
Vincent

[face_off]

Hi Vincent.

Your automated integration seems to be good, like the one choosed for the blender cycles renderer: if it is not so much work on your side, it would be great to have it integrated !

Not sure exactly what you are asking here - can you give more details pls?

Paul

[vipvip]

Hi paul

here his what i understood, but, after reading again the mail, i'm perhaps wrong:

-creation of a pict. sequence from an external app ( like after effects ) with named pictures: seq0001.jpg.....>seq0500.jpg
-when loading seq001.jpg, the plugin detects there is 500 frames ( or it is specified by the user )
-for each new frame rendering, the increment grows automaticaly ( perhaps it is here the problem ) of one step until reaching frame 500 ( and after can loop to 0001)

The solution proposed here, is automatic. If there is manual settings in this process when rendering animation ( for setteing up the new animated-texture-frame loading), of course, i think no-one will use it because it'll eat too much time...

I hope you understand what i mean

regards
Vincent

ps: here is the link of the lightwave plugin dev. with an impressive example of grass-intancing:
viewtopic.php?f=7&t=24959&p=115367#p115367
your proposition to talk to them (otoy and/or plugin developper ) about me for beta-testing still interests me a lot ( i think it would have mugh more weight if the propotition comes from your part, of course if you still feel it )