The creator of the plugin has some interesting previews over at his site   
http://preta3d.com/

Preview video  
http://vimeo.com/13596578     

Daz thread   
http://forum.daz3d.com/viewtopic.php?t=144452&postdays=0&postorder=asc&start=0  

The renderer seems to offer a relatively quick and easy fix  for Ds3A users to get some nice quality output (low priced alternative to exporting to a higher end app).  Several asked why this wasn't possible for Poser. The answer by Pret-A-3d:

*"Can't be done. Not easily. The typical scene in Poser or Studio has a pretty high number of polys. To handle all the export requirement you need C++ or you'll be waiting a looong time. I did some testing at the beginning and it was clear that an interpreted language was putting a huge bottleneck in this. Poser doesn't have a C++ API. The python interpreter has two main disadvantages: it's not fast enough and it can't be protected. Anybody writing commercial software needs to protect the work both from unauthorized eyes and from the possibility of having the code being altered by the user. The second possibility will cause all kind of tech support problems.

Right now the Poser route is not acceptable for the professional software designer. What Daz has done with Studio is the right answer. A core product that can be extended with a plugin system that is both powerful and flexible and a scripting interface in JavaScript that can be encrypted for security and protection of IP."*

Has there been any talk about Poser updating it's plugin architecture?  Is this possible or even practical?

Attached Link: http://www.renderosity.com/mod/forumpro/showthread.php?thread_id=2807269

Argh, missed that one..thanks for the linkie.

This has been mentioned in the Python forum. I am working on a script to export Poser to Luxrender and there are several other people also working on it.  Nothing yet has been released.

I dont agree completely with the comments about python, since it can be fast, and can be compiled to prevent user changes. Time will tell. 

Compiled Python is faster than interpreted Python, but even so is much slower than code written in C.
The fastest and smallest code is in Assembler, if the code is small enough it can be even more fast because it can fit in the CPU level 1 cache and run at full CPU clock .

Python script or any other script is good for user to create batch jobs or custom operations, but never for plugin or an application itself.

Quote - Python script or any other script is good for user to create batch jobs or custom operations, but never for plugin or an application itself.

ummmm....huh?? Of course it can...lol.

Laurie

this luxrender plug-in may screw things up for daz if they were hoping D|S users would
graduate to carrrara, unless the beta testers find out it's extremely slow compared to carrara.
or by analogy to poser, if they learn whether it's as slow as you'd get by maxxing out all the GI
settings in FFrender with ray-traced transmapped hair.  the carrara renderer is also slow when
maxxing out all the caustics/GI settings, but what if luxrender is alot slower and ya still gotta pay
to use it?  maybe it's a freebie in some manner, maybe alot cheaper than carrara or poser.

Paolo (Pret-A-3D) says it will be very affordable and will work with free LuxRender and free DAZ Studio. V2.0 will support animation. And it should also work with the LuxRender version coming soon that will work with CPU + GPU + network rendering. LuxRender can also work with the Amazon cloud if you need more processing power. A couple renders they posted were done in a couple hours on a single PC which is not bad for non-GPU unbiased renders. Octane Render is still much faster for now using the GPU and some of those folks let it run for a time - but their longer renders over 20 minutes are usually for scenes with little light. I've seen great Octane renders that were under 10 minutes. Some of Paolo's samples look really nice... his render of a Stonemason kit looks great (and it looked really good only after a few minutes rendering in the video sample). And there's a night time render that looks very good. The renders will depend on good textures, though, so all the really airbrushed/solarized textures I constantly see will look horrible like they do now, but nice textures will look nice right away with no shader play. The really great thing is how quickly it converts existing textures in a scene and you can still make adjustments to those or completely swap them out with better LuxRender textures.

He's contemplating making a version for Carrara and might if sales go well for the DAZ Studio version. He's not a fan of the way Carrara's plug-in setup is, but he doesn't have problems with it like he does with Poser, unfortunately. Hope some folks figure out how to do something similar for Poser, though, too.

So is this for Poser then? Or only for D/S?   If only for D/S why post it here?

OP wanted to know if there had been talk about Poser updating its architecture so we could get this, too.

Sigh. I don't converse much at Daz because there are so many people who make statements about what is possible, knowing nothing about it.

If Python is not so good at being fast for a whole app, how is it that Blender exists? Hmmm?

Python plugins can be pre-compiled - my tool matmatic is distributed that way. Nobody can see or muck with the script.

And Python can have add-on modules written entirely in C, which can go very fast. Otherwise, we would not have the Numeric library for fast vector processing.

Oh - and Poser's API is compatible with Numeric. Which means that it is entirely straightforward to write 3D manipulations that run fast as Poser Python plugins.

But what do I know.

well said Bill :laugh:

Attached Link: http://wiki.blender.org/index.php/Dev:Doc/New_Dev_Info

 As far as I can tell from an admittedly brief perusal, Python is only used as the scripting API language for Blender - as it is for Vue and Poser, or JavaScript (or even VBScript) is for Photoshop.
I emphasize only because scripting can add immense power to an application. They're just not using it to do a lot of the the heavy lifting - apparently. So, I wouldn't say Blender is a case for Python's speed appropriateness for a 'whole application'. But I'm no expert on Python or Blender and just a country programmer.

erm.. not to be an ass.. but..

who cares what it's written in should be in etc?

we work with what we've got. and without access to the core poser code / API that's python to start with. thank you, end of story, good night.

saying it should be in (insert language)  is like saying 'If I had some bacon, I could have some bacon and eggs..and if I had eggs.' aka fecking useless to getting the job done.

Agreed.  Nevertheless, I feel it worth pointing out that all (ALL) the import/export functions of Blender are written in Python.

Including the LuxRender exporter.

Quote - LuxBlend is a script that runs within Blender to set up and export Blender scenes in a file format that LuxRender understands. The script is included in all LuxRender downloads, but it takes a couple of steps to install it in the right location and make it work.

So what is the point of this line of inquiry? It's not speculation - Python works great as an exporter.

Quote - If Python is not so good at being fast for a whole app, how is it that Blender exists? Hmmm?

And why something cannot exist based or Python, Java, Perl and others?
To exist is one thing and to be fast is another.

Quote - And Python can have add-on modules written entirely in C, which can go very fast. Otherwise, we would not have the Numeric library for fast vector processing.

Python as any other scripting language to work must call functions that at low level of course cannot be written in Python.
Python calling Python calling Python calling Python calling C = very slow
Python calling C = slow
Only C = fast

The problem, first at all, is what is fast and what is slow.
And the answer is something relative to the experience that a person has.
For people that ride horses and never have seen a train a horse is something very fast.
For people that travel in trains and never saw a plane the train is also something very fast.
And the story can be continued.

The second point is like this:
My wife has a small simple green Ford Fiesta 1.3. Is amazing to see the face of the driver of an Audi, that is side by side in a crossing, to be left behind 100 meters when the green light turns on.
Lesson: Is not enough to have something fast, you must know how to use it, if not something much slower can have a fastest result.

Quote - So what is the point of this line of inquiry? It's not speculation - Python works great as an exporter.

And by adding and calling some C coding, could possibly have an interface with material previews of what the materials will look like in Lux, adjustments of those materials, etc.?

I almost wish I were a programmer. Almost....lol.

Laurie

Quote - > Quote - If Python is not so good at being fast for a whole app, how is it that Blender exists? Hmmm?

And why something cannot exist based or Python, Java, Perl and others?
To exist is one thing and to be fast is another.

Quote - And Python can have add-on modules written entirely in C, which can go very fast. Otherwise, we would not have the Numeric library for fast vector processing.

Python as any other scripting language to work must call functions that at low level of course cannot be written in Python.
Python calling Python calling Python calling Python calling C = very slow
Python calling C = slow
Only C = fast

The problem, first at all, is what is fast and what is slow.
And the answer is something relative to the experience that a person has.
For people that ride horses and never have seen a train a horse is something very fast.
For people that travel in trains and never saw a plane the train is also something very fast.
And the story can be continued.

The second point is like this:
My wife has a small simple green Ford Fiesta 1.3. Is amazing to see the face of the driver of an Audi that is side by side watching a crossing to be left behind 100 meters when the green light turns on.
Lesson: Is not enough to have something fast, you must know how to use it, if not something much slower can have a fastest result.

I love horses...

Laurie

I love cats

I write Python for a living and I drive a BMW M5. Shut up.

I write C and Assembler for a living and also drive my wife's green Fiesta....

Quote - I write C and Assembler for a living and also drive my wife's green Fiesta....

If you were listening...

You have to use Python to get the data out of Poser. Once out, you can call C code. It makes no sense to argue over which is faster and/or what bullshit....you can't do it any other way with Poser for now, so it's a moot point. Gotta be Python, at least to get it started. Arguing about it isn't gonna change what IS.

Laurie

Love you, L.

Quote - You have to use Python to get the data out of Poser.

The only data that I need out of Poser is in wavefront obj format, I don't need Python nor C for this.
And Poser 4 has no Python at all and I almost use Poser 4 even I have Poser 6 too.

The main question is people want fast renders or not?

I really don't understand this discussion. The issue is an exporter to an external renderer. It needs to export geometry and it needs to translate materials from one environment to another. The complexitity lies in the latter one and is not a speed issue. So the environment in which it runs does not really matter.
I have the strong feeling that the DS plugin developer did not want to bother with the complexity of Poser materials.

Quote - > Quote - You have to use Python to get the data out of Poser.

The only data that I need out of Poser is in wavefront obj format, I don't need Python nor C for this.
And Poser 4 has no Python at all and I almost use Poser 4 even I have Poser 6 too.

The main question is people want fast renders or not?

you do know that Luxrender does not support OBJ files. so could you please get with the program or leave?

Well gee - if Lux supported .obj files, this entire thread would be a moot point, now wouldn't it? ;o).

As for wanting fast renders? Yes and no. Yes, I want a fast render, but no, not if the end result ain't all that great. If it is great, I'll put up with as long as it takes to do the job. It's a byproduct of using 3D and not having the latest, greatest hardware. Do as many fast renders in Poser until it's set up the way you like then save the last render for Lux. Do it overnight; go take a nap; have a snack and watch the boob tube. In the end, the render quality is what I really want.

Laurie

On the subject of Poser material analysis, I already have a program that does that. VSS. VSS let's you start with somebody else's shaders, of whatever complexity, that are already loaded on your figure. It examines the shader, figures out what the maps are for, and then uses them to make new shaders. So the problem of decoding how to use the texture set is one I've already solved.

I haven't looked at LuxRender's material system yet in any detail, but if I recall from reading about it a few weeks ago, it's all based on a pre-defined set of basic shaders. For example, the architectural glass is similar to my Fresnel reflection + transparency shader. But the Fresnel reflection shader is 14 nodes, and I don't think I could write a program that recognizes that those 14 nodes are doing Fresnel reflection with an IOR of 1.4.

But I could let you mark up the shaders the way "Reality" does. I could take a guess at what the material is doing and try to pick which LuxRender shader to use, and map a lot of the parameters from Poser to LuxRender.

Any simple shader that is pretty much using a handful of lighting nodes I think would be possible to figure out automatically which material to use in Lux.

Little heuristics could be developed as well and combined to make better guesses. For example, if the specular color is the same as the diffuse color, it's a metal and should use the LuxRender metal shader.

Totally complex procedurals, like my leather shader, would be impossible to detect and understand programmatically. And any shader that is non-photoreal is also impossible.

Still, I think I could make a pretty good guess at most materials.

Quote - On the subject of Poser material analysis, I already have a program that does that. VSS. VSS let's you start with somebody else's shaders, of whatever complexity, that are already loaded on your figure. It examines the shader, figures out what the maps are for, and then uses them to make new shaders. So the problem of decoding how to use the texture set is one I've already solved.

I haven't looked at LuxRender's material system yet in any detail, but if I recall from reading about it a few weeks ago, it's all based on a pre-defined set of basic shaders. For example, the architectural glass is similar to my Fresnel reflection + transparency shader. But the Fresnel reflection shader is 14 nodes, and I don't think I could write a program that recognizes that those 14 nodes are doing Fresnel reflection with an IOR of 1.4.

But I could let you mark up the shaders the way "Reality" does. I could take a guess at what the material is doing and try to pick which LuxRender shader to use, and map a lot of the parameters from Poser to LuxRender.

Any simple shader that is pretty much using a handful of lighting nodes I think would be possible to figure out automatically which material to use in Lux.

Little heuristics could be developed as well and combined to make better guesses. For example, if the specular color is the same as the diffuse color, it's a metal and should use the LuxRender metal shader.

Totally complex procedurals, like my leather shader, would be impossible to detect and understand programmatically. And any shader that is non-photoreal is also impossible.

Still, I think I could make a pretty good guess at most materials.

Love you, BB. ;o)

Laurie

There is another option. LuxRender is open source. Which means anybody can get it, and add the ability for it to read a Poser scene file directly.

Then all you gotta do is mark up the shaders with fake nodes to tell this importer which Lux materials to use. It wouldn't have to deal with the Poser shader.

I do this all the time - I put nodes in shaders that don't do anything, but I can use them as data in my VSS script. That's how I deal with shader rules. It would be no big deal to put a LuxShader Rules material on a prop or figure. Then you'd load Poser representations of Lux shaders, edit the parameters, save the whole thing and just render it.

Quote - you do know that Luxrender does not support OBJ files. so could you please get with the program or leave?

Quote - Well gee - if Lux supported .obj files, this entire thread would be a moot point, now wouldn't it? ;o).

From LuxRender site:

Quote - Because LuxRender's file format is openly documented, any skilled programmer could start writing an exporter for any 3d modeling program.

So what's the problem, only needs an obj or pp2 or 3ds or c4d or lwo converter.
Cannot speak about Vue or Bryce because I have not the format, yet.

then put up and write one then. you know it not being a problem and all.....

Quote - then put up and write one then. you know it not being a problem and all.....

If I find LuxRender useful I shall do it.

I drive a Buick - but let's cut to the chase and just compare penis sizes instead of using proxies.

It truly depends on what you need to do and how fast you want to do it.If I want convenience,  I use Microsoft's scripting runtime file routines because present a nice object oriented interface to the file system. If I want performance, I use the Win32 API routines. You can obviously write just about any program in just about any language. You have to balance experience, speed of development, maintainability, runtime performance etc. and decide what's best. I read once that Bill Gates said he could develop an application faster in VB than anyone else using another language - but he certainly didn't try to write Windows with it. Use whatever gets the job done and floats your boat. With .NET, you can supposedly write COBOL if you want and still end up with pretty much the same result as C#. Amazing Grace. 

Someone started a Modo->Lux exporter - last heard from December 2009. C4D, Max etc. 'in development' apparently, so I don't think its a piece of cake. The only compelling thing I see about Lux is the promise of GPU and cooperative web rendering. If they get those working then it would really be worthwhile. Otherwise, FlyerX already has basic Poser to Kerkythea export in PoseRay. If BB, Kawecki or someone could add Poser material export to something like that...

N.B. Indigo has gone commercial, Kerkythea has a commercial version - none of these things my be free for long.

It wasn't using a proxy for penis size, lmckenzie. It was a proxy for speed. At the time I bought it, it was the fastest production sedan on the planet.

Who shoved the stick up your ass?

Any conversion will not be exact and you will need to edit the materials.
Try to make an exact conversion is a nonsense and useless. If you want that a scene look the same render it in its native application and don't waste time exporting and converting to foreign renderers.
Each rendering engine has its own features and personal implementation of the materials and illumination model, this is the reason why you want to use an external rendering engine: to have something that cannot be done or look better than in the native engine.
If you are able to translate in an exact way a complex Poser's shader tree and scene settings and then export to LuxRender and your conversion is perfect then you will have a Poser's render and not a LuxRender's render and you wasted your time.
If you want LuxRender' to render your scene you use LuxRender features, if you want PovRay to render you use PovRay's features and if you want Poser's shader trees you render with Poser.
You only need to translate the geometry, textures if needed and basic properties of materials (ambient, diffuse, specular, emisive, transparent, etc) and then you must setup the lights that behave in a different way and the materials that also do.

I can't understand what's the problem in doint an "slow" exporter for a renderer that most Poser people will consider slow and hard to use, even it's great, I,ve seen a lot of complain about how slow is IDL and Refract and... well so on (so will Daz Studio people when they will start using it) if some people want to try Luxrender just export in obj form from Poser, import it into Blender and test it, it's not that hard, and at the same time try Yafray, I think it's faster and easy to use, in blender at last ;-)

Look, here is a nice tutorial on how to do it, it's about Yafray, but for Luxrender it's almost the same

http://www.renderosity.com/mod/tutorial/index.php?tutorial_id=2366

so if I understand correctly to use this in poser you would need a python script that does :

create an obj in the scene to store info (like the vss obj. this could be used to store luxrender settings for the scene I think)
analyses the materials (like VSS) to find the textures, and what there for (spec, bump, diff, etc)
choose appropriate luxrender material for the poser material (god knows how you would do this, see below)
save the material data to the object and/or an external file
save camera/light info to an external file
exports the scene to an obj
start luxrender using the obj, and camera/light data from file
have lux save the scene when it closes, then read the material info from the save and load that into poser (to be saved in the scene so when you start lux again changes are kept)

for the materials, you could build a python interface that allows you to group and set lux materials before starting up luxrender.

I know thats over simplified, but thats on the right track isnt it?

Yep.

And guessing what Lux shader to use isn't that hard. You only have to look for a few things. Is there transparency and Reflect node? Thin (architectural) glass. No transparency and a reflect node with white specular? Glossy. Same but with colored specular? Metal. Refract and Reflect? Glass. No specular? Matte. Soft specular? etc.

Lets do it then. I don't want to learn DAZ. ;)

Let me know if you need any help. I should have a skeleton for an exporter script somewhere.

Quote - Any conversion will not be exact and you will need to edit the materials.
Try to make an exact conversion is a nonsense and useless. If you want that a scene look the same render it in its native application and don't waste time exporting and converting to foreign renderers.
Each rendering engine has its own features and personal implementation of the materials and illumination model, this is the reason why you want to use an external rendering engine: to have something that cannot be done or look better than in the native engine.
If you are able to translate in an exact way a complex Poser's shader tree and scene settings and then export to LuxRender and your conversion is perfect then you will have a Poser's render and not a LuxRender's render and you wasted your time.
If you want LuxRender' to render your scene you use LuxRender features, if you want PovRay to render you use PovRay's features and if you want Poser's shader trees you render with Poser.
You only need to translate the geometry, textures if needed and basic properties of materials (ambient, diffuse, specular, emisive, transparent, etc) and then you must setup the lights that behave in a different way and the materials that also do.

You're definitely not getting it.

We don't WANT an exact conversion of Poser shaders, but a good approximation between Poser's and Lux's shaders would be nice. OF COURSE the materials will need to be adjusted some (see the Reality plugin) because nothing is gonna be apples for apples between the two programs. But you have to be able to carry over texture maps with a simple approximation of glossiness, bump, displacement, etc. to get a base. Also, there is NOTHING similar between a Firefly render and Lux's lighting. Lux is clearly superior. Just like Vue's render is superior to Firefly. No one's arguing that fact. It's BECAUSE Lux's render is so much better than Firefly that anyone wants this at all.

bangs head on desk

Laurie

I really don't understand some of the resistance. Here's the deal...for those of us that would like an exporter from Poser to Lux, we're waiting with bated breath. For those that don't...no harm done. You don't have to use it if you don't want to. WHAT is the freakin' problem? If you don't want to wait for a long render, fine. Use Firefly. If you don't care how the render turns out really, fine. Use Firefly. If you wanna fight with Poser's lighting in order to get it just right, fine. That's your choice. There are some of us that would like another OPTION to Firefly and to make it as painless as possible for the shader/lighting impaired among us - our choice. That's it.

Isn't it always nice to have options? LOL

Laurie

Laurie,

In any community, there are givers and takers. The givers offer something. In an ideal world, the takers fall into two groups: those who want the gift, and those who know they simply don't need it or want it and move on quietly. But in the real world, particularly in this community, there is an annoying 3rd group.

The 3rd group are those who aren't able to understand the mechanism, purpose, or value of the gift or reject any notion that this community rewards effort and results over enthusiasm. (Symptoms of our societal "thanks for showing up" issues.) Use of the gift by others threatens or invalidates their own sense of self worth. They are envious of the value others get from the gift. Seeing others get value from the gift irritates them, and they object on various unsupportable grounds. Specious objections include: [stated with hidden message revealed)]

If you really understood Poser/Software/Art you wouldn't want to use this. [Because I don't understand this thing and how to use it, your use of this makes me look stupid - hahah guess what you are stupider than me.]

That's not important - real artists don't care about technical details [I have attention deficit disorder. Your zeal and skills makes me jealous, so I must bring you down.]

It will be slow. [I am impatient and want instant gratification, and my art reflects that bias. Yours is better, and I hate that. You suck.]

That isn't possible. [I know just enough to be dangerous but not enough to be accurate and have an inflated sense that I must share my opinions. Since I don't know how to make this gift, I will point out that your approach is doomed to failure. I will look superior.]
 

Lets all cool down a bit and see where things will go :)

Its not fruitful to argue on such things like what is possible in a programming language and what is not :)

You stated it better than I would bagginsbill ;o). But I think you hit the nail on the head...lol.

A friend mused to me just yesterday how much the Poser community comes together as a team when there is a tricky problem to be solved or a challenge and how giving everyone is of what they themselves are able to contribute (even if it's only encouragement or moral support...lol). However, we also have an enormous resistance factor - this particular example, Antonia ('why reinvent the wheel', 'why bother when there's Vicky', etc, etc.). This part baffles the hell out of me because I can see no logical reason for what amounts to discouragement. So what if someone wants use something that you wouldn't use? If it's optional and not forced upon you, what difference does it make? I can only assume then that bagginsbill is very close to the mark. That people, and artistic ones in general, don't want to see anyone else get that far ahead of what they can do themselves. It's a worthless emotion folks. You should get over it ;o).

Oh, and to Kawecki: did you know that more things have been invented/created simply because others said they couldn't be done or told the inventor that it couldn't be done? Thanks for the help, cause now the code monkeys that hang around here will just have to prove you wrong...lmao.

(I use the term "code monkey" in the most respectful, loving way...lol)

Laurie

Probably I shall do a converter, but with some limitations:

• It will not be a Poser's exporter.
• It will export from PropViever that is able to read several formats (obj, pp2, 3ds, dxf, ply).
• No shader trees, for Poser only Poser4 materials, for 3ds can be more complete, Lightwave? I don't know yet..
• You need to wait, first I am going to do an off and lwo importer for PropViever.

Quote - Probably I shall do a converter, but with some limitations:

• It will not be a Poser's exporter.
• It will export from PropViever that is able to read several formats (obj, pp2, 3ds, dxf, ply).
• No shader trees, for Poser only Poser4 materials, for 3ds can be more complete, Lightwave? I don't know yet..
• You need to wait, first I am going to do an off and lwo importer for PropViever.

That's nice :o). Doesn't belong in this thread then tho...lol.

Laurie

From what I can see you cant just export the geometry, it appears to need to be broken down by material. So its read the poser scene, write the lxs file info for camera and lights, then go through all the geometry, break it up by material and write that to the lxs file . 

Theres a bunch of info that I am simply writing in as a default because I dont understand it completely yet. Nothing in it seems hard, just a lot of stuff to code.

I didn't find yet in the site where is the lxs file format description, it must be somewhere!