I'm just in awe here... and wishing I could do more than just moral support right now (can't help with the programming... I didn't just fail my C exam, they took the paper out and burnt it before it could contaminate the rest of the training center....)

Quote - > Quote - Use of Yaml with Poser-Python needs an external package  to be installed.

No it doesn't need to be "installed" if you mean into the Poser Python folders.

You should phrase such statements as questions. I'm sorry, but I find it irritating when people say "this must happen" or "that can't happen. Sorry.

Had you asked "How did you incorporate YAML into the exporter?", my answer is:

Thanks for correction.  :)

Quote -
There is a C version in the package as well, and that would need to be installed. But I'm not using that one. The C version is only really important to get performance when reading/writing huge documents. For config files, even if they are 50K (which they won't be) the pure Python version is perfect.

Ok. For windows I found a typical installer package (EXE) for Python 2.4. If there is a Python only lib delivered with the source anything will be fine.  

Quote - Note that even though I am loading and analyzing every single node in every single material, I have never seen the Material converter take more than 1/10th of a second to finish its job.

It's so fucking fast that anybody who argued about material conversion complexity should go hide.

:biggrin: :biggrin: :biggrin:

Quote - > Quote - > Quote - @BB: if developing GUIs in Flex is as nice and easy as you say, you might even win me over eventually. :laugh: 

Just a question: What about P5/P6 users? At least P6 is still used by a lot of people.
Maybe an external Webpage?

I'm not understanding the issue you're considering.

My GUI runs on any computer, even one that has no copy of Poser installed.

It simply reads and writes the exporter config file. It's just a document editor.

From Poser Python, I plan to run the MatConverter and produce a YAML file listing all the

You see it as at least 2 seperate "apps"/user-interfaces? Global parameters for the Lux renderengine, other sets/conversions/options and a more or less "stand-alone" material exporter?
(This is a question :) )

Quote - > Quote - That's great BB!

What worry me is that people wants Lux simply because DS has it, and maybe with your tool will miss the opportunity to have a better suited renderer.

Have you tryed any? what should a renderer have to be the better one for scenes with humans? considering you are The Shader Mater ;-)

I was just going to post a small lil "posting to keep up with thread" but that made me want to write.
Some of us simply do not like daz studio.
I am not saying it isnt a good program.
I am not saying it doesnt render well.
I am saying some of us would rather not be forced into using it.
I prefer poser. 
I -have- tried daz...and do not like it.
With that. those that do not like it shouldnt be forced into using it.
We should have the option of plug-ins for poser., Just like DS has plug-ins.
This lux render looks promising. Not sure if my system would even deal with it. but It looks interesting.
I am confused why there would even -be- opposition to this. (yes I have read a good deal of the thread)
Why cant plug-ins be created for both programs without a tizzy being thrown over it?

  Er, I believe the poster of the first comment meant, why use Lux in particular, just because D|S is, when there might be a third-party renderer that's better suited for the rendering of human figures?  It's a valid question - there are several open-source raytracers out there, and apparently Lux is having troubles with advanced math functions, if nothing else.  On the other hand, it being open-source, one can write an offshoot that has the necessary functions, as BB mentioned.

  But, there was talk of porting to other renderers as well... this could be just a jumping-off point.  It all depends on how well this goes, and how much sanity these guys will retain in the process.  

 This has all been fascinating to read.  My math skills are terrible, so I'm not understanding much of the equations, but it's exciting to see it being applied to translate from one program to another.  I'm cheering all of you on.  

Quote - , and apparently Lux is having troubles with advanced math functions, if nothing else

Actually it does the advanced math really well and automatically - Fresnel reflection equations, for example are automatically used in every shader. In Poser I have to add those myself. In LuxBlend there are dozens of complicated noise pattern generators - Poser only has a few so I often have to build new ones by combining simpler ones.

No, what is missing in Lux are simple math functions for shader building. Add, subtract, divide - these are missing. Obviously the designers have a world view that does not include a user making new kinds of complicated patterns from simple math. They view the world of users as unable to create complexity from simple pieces, so they leave it out, I suppose.

But even though Lux's higher-level texture components are great, they can't produce every pattern needed, and one needs to be able to assemble those. Well, I do anyway.

Traditionally this sort of thing is done by adding more code to the engine, which means it isn't user extensible. I prefer the modular component approach where it is rare to need to add a new kind of component, because practically anything can be built from the existing ones. And they almost have that in Lux. In Poser we have it in spades. And recently DS added the same thing - component (node) based shader assembly instead of coding new modules.

My problem with Lux is not that it isn't component based - it is. But there is a fundamental set of minimum components that have to be there in order to build new kinds of shaders, and these are missing. The interesting thing is that each is different from the existing components by only ONE LINE OF CODE.

For example, they already have a multiply component called "scale". It returns a * b.

Copy/paste and change the name to "add" and then change the expression to a + b. Done.

Do that for:

divide    a / b
pow pow(a, b)
log log(a,b)
exp exp(a, b)

etc. These are not complicated components - they are one line of C++ code.

@bagginsbill: your plan for separating the GUI from the program core sounds excellent. I like to loosely-couple the heck out of things wherever I get the chance.

(Little anecdote: one of my projects at work is developing and maintaining an online meta-data browser for a research group who specializes in volume data analysis. For some reason, everyone assumes that the automatic import and slice image generation functionality is implemented as part of the web server's code base, written in Ruby on Rails. Why the heck would I do that? For one, Ruby doesn't have anything even remotely equivalent to numpy and PIL, so for someone like me, who doesn't particularly like writing huge chunks of C/C++ code, Python was the natural choice. Also, it's much easier to add new kinds of data if the preprocessing is done separately and the results sent to server via HTTP, using a human-readable specification format. Finally, I don't have to worry about how the web server will get access to the actual data repository, and how to handle permissions and all that jazz.)

ADP, can I make a request? It would be really helpful for me if we could drop the version numbers on individual source file names. Just include a version number in the directory name and in the package attributes. That way it's much easier for me to use something like 'diff -r' to figure out what the changes are between versions and which files I need to update in my work folder.

Quote - ADP, can I make a request? It would be really helpful for me if we could drop the version numbers on individual source file names. Just include a version number in the directory name and in the package attributes. That way it's much easier for me to use something like 'diff -r' to figure out what the changes are between versions and which files I need to update in my work folder.

Yes, fine.

With this I can easier extend web-requests.

Anybody able to create sort of a prolog for the sourcecode files? I would like to add this text automatically to each sourcecode file.

Quote - Anybody able to create sort of a prolog for the sourcecode files? I would like to add this text automatically to each sourcecode file.

What kind of prologue do you have in mind? Something like a copyright notice? Maybe you could post a short summary of what you'd like to put in there, and one of the native speaker could polish it up. I've just had my delusions that my writing style does not reveal me as a foreign devil utterly shattered the other week.

Something completely different: has anyone else noticed that the "world normals" that Poser produces are pretty wonky? It seems that at vertices with no polygon smoothing, it picks one of the face normals at random. With polygon smoothing, it's even stranger. Sometimes I get the correct averaged normal, sometimes I don't. This is easy to see by importing a simple object like a cube and looking at the exporter output. I'm not sure how this happens, and if there are any ways of avoiding it. Lux apparently renders ugly things if it doesn't get fed any normals.

If we end up having to compute our own normals in the exporter, things are going to get "interesting". From what I've seen, numpy has a cross product, but Numeric doesn't. Adding a numpy dll just for this seems a bit excessive, so it would have to be some creative index mangling in Numeric in order to compute many cross products simultaneously, or else a little C extension for computing the normals. Well, at least it doesn't look like I'll have to look for a new job within this project too soon. :mellow:

Argh! Apparently, Lux does not like to UV-map quadrangles. I'm not completely sure what it does, but from the examples I rendered, it seems to just smash the complete texture on every single quadrangle. Triangles seem to work fine, though.

Also, it looks like Lux flips the V axis relative to Poser. I need some more tests, but I think I am now really close to getting the UVs out properly.

Do NOT flip the V axis in geometry. Some shaders have an expectation of what V=0 and V=1 and V=.5 mean on a prop. That will screw up the knowledge I have about UV on a geometry. I will not be able to put grime at the bottom of a wall if you flip it. It will flip to the top.

I take care of the V flip in the shaders. Already done since 3 days ago.

Alright then! I'll make it configurable and let the default be not flipped.

How can I make a simple Lux shader the does the V flipping for me? It's irritating when I try to check the mapping and everything is upside-down.

BTW, forget my last question! I'll just use an upside-down image map for testing. facepalm

Quote - Alright then! I'll make it configurable and let the default be not flipped.

How can I make a simple Lux shader the does the V flipping for me? It's irritating when I try to check the mapping and everything is upside-down.

The flipping of V is not in geometry, but in the interpretation of image maps. In all other ways, UV is the same between Lux and Poser.

It is the imagemap texture that must be flipped. This is done with the vscale parameter - use -1 instead of 1.

My mat converter already demonstrated this. I showed an image mapped texture yesterday and showed you the material. Look over the output I generated yesterday and you will see lots of interesting things.

Image_Map

Texture "ImageMap" "color" "imagemap"
"string filename" ["C:Documents and SettingsTC250065DesktopTedTexturesConcreteDSC_7664.jpg"]
**"float vscale" [-1]
**"float gamma" [2.2]

Quote -
The flipping of V is not in geometry, but in the interpretation of image maps. In all other ways, UV is the same between Lux and Poser.

It is the imagemap texture that must be flipped. This is done with the vscale parameter - use -1 instead of 1.
[/quota]
Ah, good! I didn't think of that. That's easy, then.

Quote -
My mat converter already demonstrated this. I showed an image mapped texture yesterday and showed you the material. Look over the output I generated yesterday and you will see lots of interesting things.

I shall study it with much interest.

Why is it such a strange shape, though? That's because we had to split vertices along texture seams. Lux does not realize that the two copies of the vertex on both sides of the seam are really meant to be the same, and consequently treats the texture seam as a sharp edge. We'll get the same effect if we use some low-poly Poser figure and smooth it out using mesh subdivision. Wherever there's an actor or material boundary or a texture seam, we'll have a more or less sharp edge across which Lux can't interpolate (although if we export sensible normals, the shading will still look fairly smooth). At the moment, I see no way of fixing this in general (except of course by modifying Lux itself). It may be that we can get rid of the seams at actor boundaries by exporting a fully welded geometry for each figure instead of a separate one for each actor, but I haven't tested that yet.

I had some artifacts supposedly due to wonky normals when I was still passing the quads through as they were. I don't see those problems anymore. So the normals seem to be close enough to what we need, at least for this kind of object.

I'm going to strip the quad-specific code from the exporter for now and export a pure triangle mesh. If and when Lux gets updated to handle quads correctly, I'll bring the quadrangle support back in a different way which will complicate the source code less.

What I am truely astouded by here, is that a few individuals (very apt ones at that) have developed a product that most would pay some fairly substantial money for.

You saw the need and thought, "That would be kwel" and went and did it.
Bravo, bravo, bravo!

WOOT!!!

Laurie

odf, I am out of action on the weekend so that my wife doesn't divorce me, and I have quite a bit of work on Monday and Tuesday, but I will be contributing again at full speed on Wednesday, I hope.

I'm just popping in to give a heads up as to what I'm thinking of doing, so that you can use this information to make wise choices.

Here is the crucial thing to understand: I see enough things wrong with the Luxrender, as-is, that I believe I do not want to use it, and do not want to make an exporter for it. The fact that it does not understand the dichotomy of a closed loop geometry with simultaneously an open loop UV seems a deal breaker to me. I insist that a realism renderer be able to do smoothing at least as well as Poser, not worse.

Second, the lack of straightforward, even trivial, texture manipulation is simply moronic. I do not accept the idea of a "more powerful" renderer that is a step down in features from Firefly.

So - I am planning to (for free) make and maintain an improved Luxrender, one that has all of Lux goodness, plus the goodness of procedural textures and the ability to do organic geometry well instead of poorly. Note that I am not referring to procedural shaders (which allow people to do stupid unrealistic and wrong things with light), but procedural textures (which allow people to do beautiful things with diffuse color, specular color, refraction color, reflection color, transmission color, bump, displacement, and transparency.). This is a subtle difference and it may be lost on some people, but they'll have to trust me that I know what I'm talking about and I could make it clear but do not have time to explain it. I'd rather spend my time building it than explaining it.

While I'm in there messing with the C++, there is absolutely no reason that I should not add the ability to read OBJ format geometry directly. I find it incredibly disingenuous, even perhaps a bit stupid, that an OBJ geometry reader is not built into LuxRender from day 1. The format that was introduced is not superior in any way - quite inferior really.

My latest thoughts on the config options GUI -

I am building an application that reads YAML that tells it what to edit. You will not have to code anything, nor will I. You will describe a configuration in YAML. You will describe hints of how to edit said configuration (where needed) in another YAML. The GUI will build itself from the self-describing configuration and side-car hints file.

To add new properties to the config tool will be zero work. I mean zero.

Quote - My latest thoughts on the config options GUI -

I am building an application that reads YAML that tells it what to edit. You will not have to code anything, nor will I. You will describe a configuration in YAML. You will describe hints of how to edit said configuration (where needed) in another YAML. The GUI will build itself from the self-describing configuration and side-car hints file.

To add new properties to the config tool will be zero work. I mean zero.

Sounds great! I've actually done something very similar for a project at work, with HTML forms. The data as well as the instructions for building the form were coded in YAML.

As for the improved Luxrender you're thinking of, I hope that there will be a way to merge your additions back into the main stream at some point, since I'm assuming there will be further development on that.

Quote - As for the improved Luxrender you're thinking of, I hope that there will be a way to merge your additions back into the main stream at some point, since I'm assuming there will be further development on that.

That shouldn't be troublesome, Lux is GPL, so the only two criteria are

1. the additional code can be GPL'd (not much can be done if it can't)
2. the Lux project decide to include it (could be distributed as a patch provided 1) is fulfilled)

The addition of new texture ops to the Lux source does not require any changes of any kind to existing source. Geometry loaders might be similar. I haven't looked that far.

The architects do everything right in the Lux source. Objects are self-registering, components are unaware of each other,  everything uses inline code where possible - it's a lovely code base.

is there a similar renderer that is able to render realistic iamges and also supports SSS? and could be used as a pose renderer?

Similar as in free? Similar as in unbiased?

Kerkythea has unbiased SSS in a free renderer. But it is missing displacement I think.

I don't really know. Start a new thread.

Quote - Similar as in free? Similar as in unbiased?

Kerkythea has unbiased SSS in a free renderer. But it is missing displacement I think.

I don't really know. Start a new thread.

FWIW, it's not easy getting Poser scenes into Kerky, even with PoseRay. You still have to set up every single texture by hand. Doable, but takes forever. Good luck with that ;o).

Laurie

i read the daz tool has been submitted to the store. it will be interesting to see the images people will get out of it. 

Quote - > Quote - Similar as in free? Similar as in unbiased?

Kerkythea has unbiased SSS in a free renderer. But it is missing displacement I think.

I don't really know. Start a new thread.

FWIW, it's not easy getting Poser scenes into Kerky, even with PoseRay. You still have to set up every single texture by hand. Doable, but takes forever. Good luck with that ;o).

Laurie

But Laurie - Poseray doesn't understand Poser materials. I do. I could easily write an exporter for Kerkythea as well. Easily.

BB, you guys just amaze me.   I'll be hanging on watching with bated breath.

Thanks so much for what you are doing.

I agree.. I am waiting as well :)  BB.. one of these days I am going to ask to borrow some of your time so I can pick your brain about some stuff please :)

Quote - > Quote - > Quote - Similar as in free? Similar as in unbiased?

Kerkythea has unbiased SSS in a free renderer. But it is missing displacement I think.

I don't really know. Start a new thread.

FWIW, it's not easy getting Poser scenes into Kerky, even with PoseRay. You still have to set up every single texture by hand. Doable, but takes forever. Good luck with that ;o).

Laurie

But Laurie - Poseray doesn't understand Poser materials. I do. I could easily write an exporter for Kerkythea as well. Easily.

did someone show him the master plan???  damnit you know he won't sleep.....

I'd like to see exporters for Lux, Kerky, Indigo....all that someday ;o). If it's possible (and of course it is)....lol.

And I know you could write an exporter for Kerky BB...I was just letting ice-boy know that in the absence of a current direct exporter, it's not so easy right now. I didn't want you get sidetracked from your Lux exporter either or drift the thread too much...lol.

Laurie

Quote - The architects do everything right in the Lux source. Objects are self-registering, components are unaware of each other,  everything uses inline code where possible - it's a lovely code base.

That's good to hear. Maybe I should take a peek at it myself, then. You know, just out of curiosity for now. But if you ever need someone to help out with the math, or do some mesh mangling for you, give me a holler.

Quote - Here is the crucial thing to understand: I see enough things wrong with the Luxrender, as-is, that I believe I do not want to use it, and do not want to make an exporter for it. The fact that it does not understand the dichotomy of a closed loop geometry with simultaneously an open loop UV seems a deal breaker to me. I insist that a realism renderer be able to do smoothing at least as well as Poser, not worse.

This was the worst that I found and the second that a vertex cannot be common to different materials.
The problem of Lux per vertex texture mapping is the same as 3ds and I don't don't how 3dsMax solves this problem and it is a very expensive software! Don't know the max format, maybe in max format you can do mapping as in obj, but 3ds is the same as Lux. Well, Lux is worst, with 3ds you can have different materials sharing a vertex.

The thing that make me lost interest on Lux some time ago was that is very slow. If it should have a normal speed it could be useful at least for some experiments.

Quote - I am planning to (for free) make and maintain an improved Luxrender, one that has all of Lux goodness, plus the goodness of procedural textures and the ability to do organic geometry well instead of poorly.

That's nice, but if tomorrow you win the Lotto and retire on a paradise island in the Caribbean to perfect your tan (that's all I wish you) people will be stuck in Limbo.

Better make the Lux team accept those changes as official; After all it's open source, and I'm guessing the people who have build it so far won't refuse those improvements, especially if they don't require any work on their parts, and mean increasing all of a sudden their user base tenfold - even if they didn't see the point so far... 

As for using Luxrender instead of another renderer - People, think about it from a "content" point of view.
Lux compatibility might be the future for both Poser and DAZ Studio, allowing merchants to offer common Lux materials, for both Poser and DAZ Studio users to use. Finished the dumbed-down versions and the additional workload of making two different versions for the price of a single one: Just make Lux the official high-end renderer of both apps!
Smith Micro should definitely think about including the exporter/converter into Poser 9.
Unless of course they have a Firefly update ready, making it superior to the (current) Lux version (Somehow I doubt they do).... They have lost the content battle (by KO, since the first round), so their only hope (and ours too) is to refuse the battle they can't win, and rally under the neutral flag of Lux, which adds tons of perceived value to Poser, for very little cost.

Quote - The thing that make me lost interest on Lux some time ago was that is very slow. If it should have a normal speed it could be useful at least for some experiments.

Maybe it's time to take another look, then? Honestly, with the settings bagginsbill posted a few pages back, I get a first rough impression of the render within seconds and a decent preview in less than a minute. Of course those times will depend on the image size and the complexity of the scene, but I'm already finding this much more pleasant than doing test renders in Poser.

Quote -
Better make the Lux team accept those changes as official; After all it's open source, and I'm guessing the people who have build it so far won't refuse those improvements, especially if they don't require any work on their parts, and mean increasing all of a sudden their user base tenfold - even if they didn't see the point so far... 

Well, he can't make them do anything, can he? He can submit a patch (or patches) against the official version and hope that they'll take it. I can only assume that's what he's aiming for. But distributing his modified version separately for a while and demonstrating what can be done with it is not a bad strategy for convincing the core developers that his contributions are worthwhile, and it might save the rest of us from having to wait until they find their way into the official Lux.

Nothing wrong with forking a code base if necessary.

Edit: Of course if bagginsbill goes and fixes Luxrender's import functionality, this will all become less interesting. But I'd like us to have a fighting chance of getting nice renders out of Lux in the meantime, so I'll just go ahead and give this the finishes touches. Then I'll have a look at converting lights and cameras, if no one else has done that yet.

odf,

I think what you're doing is useful regardless of whether or not I fix the Lux loader facilities. We have the possibility of building other exporters from this codebase - perhaps other renderers will require pre-computed normals and they are not all open source.

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

1) The Lux guys have not included any other special features to accomodate any other exporters, except for Blender. The only reason they accept Blender is they all use Blender.

2) The CG community as a whole would feel that Luxrender would be a disgusting tool if it had anything in it tainted by Poser. We Poser users are the "shit eaters".

If I'm wrong, and they would like the changes, well that doesn't alter anything I'm doing. When I have the changes mature, I will offer them to the Lux developers. If they want it, they can have it. If they don't, then I really don't care.

Quote - 2) The CG community as a whole would feel that Luxrender would be a disgusting tool if it had anything in it tainted by Poser. We Poser users are the "shit eaters".

So sad, and yet so true I'm afraid ;o).

Laurie

"Edit: Of course if bagginsbill goes and fixes Luxrender's import functionality, this will all become less interesting. "***

Well to be Fair "Fix" implies that this Free render engine is somehow "broken".
Perhaps "Altered to fit posers formats" is a better description.

The programmer who is about to release the DAZ exporter will be distributing an "off the shelf", unaltered Copy of Lux Render for Windows&OSX along with his plugin
(perfectly legal under open source)

It seems this whole reactionary  effort thus far has been  to"prove the naysayers wrong" and keep up with the DAZ Crowd.

Lux Render in its current iteration is a photo realistic Architectural Visualization solution Much Like Maxwell and to a lesser extent Vray.
most of that Canned Poser/DAZ content that is NOT of the high quality
of "Stonemason's" building set pieces are going to look like CRAP in LUX
Just as it does in Vray&Maxwell and those gleeful D/S users will soon learn this Bitter fact for themselves.

BTW I am speaking from The perspective of someone who has
POSER, MAXON Cinema4D R11 with AR3&Vray+ interposer pro 1.99
Maxwell render 1.7, MODO401 and of course LUX Render
of course NONE of the Expensive render engines literally translates Duplicate poser Skin shading system/solutions

Nor should they.

Whenever  a discussion comes up about rendering poser content in other programs  the inevitable Deal Breaker is" will my Naked vickie's skins & hair look the same as I am used to seeing"
Admittedly no one actually says this but all of the demands for more sample skin /hair renders,like over at the DAZ Forum thread ,Make it obvious what the prime concern is.

If people truly want better human renders with true SSS etc they need to swallow
the reality that they need to build them both mesh and Shaders for whatever render engine they are targeting
Just have a peek at the Galleries over at CG Society.org  for example.

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.

Cheers

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.

Quote -
It seems this whole reactionary  effort thus far has been  to"prove the naysayers wrong" and keep up with the DAZ Crowd.

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.  I started this thread, not to foster the "keeping up with the Jonseses..over at Daz" mentality, but because Poser has room for growth. I was hoping that by bringing such changes at Daz to the public eye here in the community, some might take on such a task.  In this case, I consider myself fortunate to witness such an attempt.

You seem to enjoy praising Daz because they are taking such steps to increase it's capabilities, modernize it's code base, etc.  Daz looked at many Poser features during its development and implemented it's own iterations.  Should not Poser and their very talented programmers, also be encouraged to do so? 

I would also like to see radical changes to Poser.  Encouragement of community driven efforts such as this are important and necessary, if for no other reason than to show what the other guy is doing and thus provide the impetus for change.