Quote - This thread is almost done once the beta is out.

we are FAR from a Beta.

 quote:-
"a rey(Poser) render does it 100 times faster? "

I don't think poser does this satisfactorally really.  Also there may be something neat with the lux render engine like angle of incidence shaders (like in vue) or something and a one or two click way of applying.  That's why I asked.
I know lux is designed for reality but I don't know what it is capable of doing and I wondered if tooning was something it might be capable of because it seems to use fairly simple shaders.  I still would not be surprised if someone does hit on something that does this one day with lux.
BTW I do not call a thick black line all the way around an object tooning.  Also I looked at mangastudio and it is not the look I'm after either.
Anyway I got my answer early on when I posted, when someone said there is probably a different render engine that would do it better, and using the ideas they have grasped from exporting to lux they well maybe able to make exporters to other render engines that may be more suitable for tooning.
Love esther

Quote - there is probably a different render engine that would do it better, and using the ideas they have grasped from exporting to lux they well maybe able to make exporters to other render engines that may be more suitable for tooning.
Love esther

That would make sense to do.  I'm always on the lookout for a good toon renderer for different style graphic novel type art.

so we had some problems with smoothing on reflective objects right? and glass?

i found an old thead on Luxrender forum about this. its back from may june. yet it looks like the bug is stil there right?

www.luxrender.net/forum/viewtopic.php

Quote -
Anyway I got my answer early on when I posted, when someone said there is probably a different render engine that would do it better, and using the ideas they have grasped from exporting to lux they well maybe able to make exporters to other render engines that may be more suitable for tooning.

I would like to see Aqsis as the next candidate. Mutch easier to convert Poser materials, because Aqsis is using the same type of material-definition (RenderMan standard). 

See http://www.aqsis.org/

But now back to LuxPose :)

Fryrender, a commercial physically-based unbiased renderer, has a toon render core so it is not impossible for luxrender to have one, although I don't  think the current developers has any interest.

The main difference between biased and unbiased renderers is in the lighting calculation. The material/shader system in luxrender is based on the same models used in biased renderers.

**LuxPose version 1.20
**
No big changes yet. Light grouping works. To use it, rename your lights like this:

Original Names, : Light 1, Light 2, Light 3
Rename to: GR1:Light 1, GR1: Light 2, GR2:Light 3

In Lux-GUI you will see two lightgroups after export: GR1 and GR2. Now you are able to adjust intensity (gain) and color of each lightgroup individually.

You may use any strings insteed of "GR1", "GR2".  The groupname is the part before ":".

Other additions: Infrastructure to support texturename/texturepath substitution. Needed for network rendering etc. No connection to GUI yet.

pciccone who created the Daz exporter for Luxrender wrotte this on the lux forum 1 week ago.

''- Skin material. We have debated the use/faking of SSS but I'm actually thinking of skin material like the other basic materials, glossy, glass etc. The reason is simple, faking it is a lot of work and it's not always working out of the box. The human skin is partially glossy but with a shine that is unique. A skin shader would make life a lot easier and lead to more realistic results.''

this is the answer that he got.

A "true" skin material would require a multilayer BSSRDF (bidirectional surface scattering reflectance distribution) which it a bit involved to introduce. I've seen a couple of approaches in pbrt which typically ends up being implemented as a special case integrator with various preprocess steps. I doubt your users are interested in making the various layers of *dermis maps etc that is needed "Ordinary" SSS doesn't work very well for skin either, it usually just makes the models seem like wax or plastic. So perhaps a variant of your "hack" (matte translucent + glossy) combined with a asperity scattering BRDF would be a better approach for this (asperity: see for example http://bit.ly/c0axBU)

I would like to add that your users' use of the "simple hack" brings pretty amazing results already!

EDIT: I'm implementing the "The Secret of Velvety Skin" BRDF (paper linked above) in lux just to see how it looks and if its worth having

http://www.luxrender.net/forum/viewtopic.php?f=27&t=4487&hilit=fireflies

is this a joke or what?

why don't you ask them

we're not mind readers...

It's not a joke. They just implemented the brdf velvety texture in the lastest Luxrender Linux build. The rest of us will have to wait a little longer ;o).

Laurie

forget about the velety texture.

it makes me angry what kind of opinion Lux users have about the SSS.

curve contrast in photoshop. everything else was done in Luxrender 0.7

Quote - forget about the velety texture.

it makes me angry what kind of opinion Lux users have about the SSS.

And you're the only one that's been screaming for it. Seems the rest of us are willing to use a workaround. We ARE Poser users after all. We're quite used to workarounds.

The velvety textures will help a lot, and not just with skin. I'm glad they added it. It's a free renderer - you can't have everything you want. Unless you wanna pay for it, that is.

Laurie

Quote - in other news ice-boy is official addicted with glossy reflection. ohhhhh f.... yeah.

curve contrast in photoshop. everything else was done in Luxrender 0.7

Very cool :o). One of Xurge's?

Laurie

Quote - > Quote - in other news ice-boy is official addicted with glossy reflection. ohhhhh f.... yeah.

curve contrast in photoshop. everything else was done in Luxrender 0.7

Very cool :o). One of Xurge's?

Laurie

Cyber suit.

SSS tends to be computationally expensive (at least on the render engines I've tried it on so far) so if there's a hack which looks good enough then it might be an idea to use it.
Most scenes you probably wouldn't notice the difference on humans

Quote - SSS tends to be computationally expensive (at least on the render engines I've tried it on so far) so if there's a hack which looks good enough then it might be an idea to use it.

Agreed it (SSS) slows Down MODO401, Vray&Maxwell Substantially!!!!.

I have yet to see SSS that looked right in general on CG characters. The only time it helps is when ears or maybe hands are backlit. But generally you don't even see that in movies or real life. Velvety skin has been missing and all the most realistic CG renders I've seen of humans are softly lit. Looks to me the Lux developers are on a better track. Fryrender has SSS and even a variation which still doesn't look real on characters in their gallery, but does look good on leaves and static objects. But as has been proven over in the Octane Render forum, translucency can work just as well for leaves and some objects.

Kevin

MentalRay has a fast skin SSS shader but it's a right pig to set up and if you don't get it exactly right, it looks like crap

Quote - EDIT: I'm implementing the "The Secret of Velvety Skin" BRDF (paper linked above) in lux just to see how it looks and if its worth having

http://www.luxrender.net/forum/viewtopic.php?f=27&t=4487&hilit=fireflies

is this a joke or what?

SSS is great for bars of soap, candle wax, plastic toys.  But for human skin, marble, ruby, even granite there is no way for SSS to achieve realism.  That's where BSSRDF comes in.  Lux and others have the material and lighting thing down.  It's what people are hoping to achieve with Lux and the other renderers is where things begin to fall apart.

i promised i will stop talking about this. so thanks.

YES! I figured out my problem and why LuxRender kept crashing! :thumbupboth: The problem seems to stem from not having enough memory on my laptop (only 2 GB) but I was able to over coming this problem by removing a lot of the references to the same picture over and over again. I had to go LXM file and just have the repeat textures check the first instance of the image and then remove all other references to those images. Once I did that, it stopped crashing on me.

I think my explanation makes little to no sense of what I did to fix the problem...

I only have 2Gb on my machine too, the problem is any renderer has to load the textures it's going to use into memory, if you're asking it to load "300" copies of the same thing & that uses up all the memory it'll crash.

What were you trying to render?

It wasn't much, I don't think... M4, Shorts from Casual Wear, Glynn hair, and forest from Multiplane Cyclorama. Most of the corrections I had to do was with M4

I haven't seen anyone else mention a problem like that with M4, but then I'm not sure if anyone else is actually using him with LuxRender, this might even be a bug in LuxPose that the guys haven't seen yet.

Quote - ...if you're asking it to load "300" copies of the same thing & that uses up all the memory it'll crash.

IMHO any render engine that fails to notice that a texture mentioned in 10 different skin shaders is the same file, and thus ends up loading ten copies of the decompressed texture into memory, is broken.

Quote - > Quote - ...if you're asking it to load "300" copies of the same thing & that uses up all the memory it'll crash.

IMHO any render engine that fails to notice that a texture mentioned in 10 different skin shaders is the same file, and thus ends up loading ten copies of the decompressed texture into memory, is broken.

Lux does not load the same texture more than once. Look into Lux-log to see which images are just referenced while loading.

 I did, that is how I found the problem, that and having task manager open to watch how much ram was being used.

I may have written this down already, but I cannot find it today.
Question: When editing the LuxRender Material, "lxm File", beside "glossy", what other choices do I have?

TKS

 Maybe I am wrong... all I know is that my computer does not seem to like all of the 

Image_Map_3

Texture "ImageMap_85" "float" "imagemap"

"string filename" ["C:UsersClayDocumentsDaz 3DStudio3ContentRuntimetexturesMorrisHiro4JMHiroLimbB.jpg"]

"float vscale" [-1.0]

"float uscale" [1.0]

"float gamma" [1]

over and over again with the only difference really being the number attached to the "ImageMap_

and when I get rid of all those and make others point to first ImageMap_85 with the file attached it works, when I leave all the others in it crashes... and now that isn't the only one that does it for, just an example of one of the images that comes up over and over again in the lxm file.

Quote - > Quote - ...if you're asking it to load "300" copies of the same thing & that uses up all the memory it'll crash.

IMHO any render engine that fails to notice that a texture mentioned in 10 different skin shaders is the same file, and thus ends up loading ten copies of the decompressed texture into memory, is broken.

You must be talking about some of Vue Infinite's latest updates.  Out Of Memory errors just for importing a Poser figure (that happens to have the same texture map for every knuckle on every hand on every arm).  Madness.

Quote - I may have written this down already, but I cannot find it today.
Question: When editing the LuxRender Material, "lxm File", beside "glossy", what other choices do I have?

TKS

The other choices so far, are  - carpaint

• glass
• glossy
• matte (default)
• mattetranslucent
• metal
• mirror
• mix
• null
• roughglass
• shinymetal

You'll find all the possible choices and their parameters on the Luxrender wiki, http://www.luxrender.net/wiki/index.php?title=Scene_file_format#Materials

Quote -  Maybe I am wrong... all I know is that my computer does not seem to like all of the 

Image_Map_3

Texture "ImageMap_85" "float" "imagemap"

"string filename" ["C:UsersClayDocumentsDaz 3DStudio3ContentRuntimetexturesMorrisHiro4JMHiroLimbB.jpg"]

"float vscale" [-1.0]

"float uscale" [1.0]

"float gamma" [1]

over and over again with the only difference really being the number attached to the "ImageMap_

and when I get rid of all those and make others point to first ImageMap_85 with the file attached it works, when I leave all the others in it crashes... and now that isn't the only one that does it for, just an example of one of the images that comes up over and over again in the lxm file.

Lux is using FreeImage to deal with images. Maybe your images are "not compatible" with this? Hm. Poser uses Freeimage also. But anyway: Try to open one of the problematic images with an Image-Editor and save it again. 

Or is the imagepath a "virtual path"? I have had some trouble with network pathes. Sometimes it worked, sometimes not.

Quote - The other choices so far, are  - carpaint

• glass
• glossy
• matte (default)
• mattetranslucent
• metal
• mirror
• mix
• null
• roughglass
• shinymetal

You'll find all the possible choices and their parameters on the Luxrender wiki, http://www.luxrender.net/wiki/index.php?title=Scene_file_format#Materials

Thanks
Link saved to favorites and information Copied and pasted to a Saved File.

Quote -  
"string filename" ["C:UsersClayDocumentsDaz 3DStudio3ContentRuntimetexturesMorrisHiro4JMHiroLimbB.jpg"]

Another idea: Is Lux able to access the images? Often Poser and DS are installed as administrator. So the administrator owns all images. Maybe a standard user (Lux) are not allowed to access them ...

Nobody with new images here?
Show us your tests! 

Quote - Nobody with new images here?
Show us your tests! 

Rendering now.

Quote - Nobody with new images here?
Show us your tests! 

Gladly, but how do you attach an image to a post and what size/properties?

Quote - > Quote - Nobody with new images here?

Show us your tests! 

Gladly, but how do you attach an image to a post and what size/properties?

I use often 800 in X (use JPG images to save space).

Below the input field (where you type your message) you read: "Attach a file" and a button to select your image. Do this and - to be sure - click "Preview Reply". You should see your image then.

Quote - Nobody with new images here?
Show us your tests! 

I put mine in my gallery, http://www.renderosity.com/mod/gallery/browse.php?user_id=627255

And I've currently got a test rendering at home of the close-up portrait I posted 2 days ago, this time with skin material changed to mattetranslucent.. not sure how that's gonna look, it looked a bit strange in the first 5 minutes before leaving for work. :p

Attached Link: There Will Be Grease

Quote - I'll post one when it finishes baking.  May be a while.  Meanwhile see link to one in my gallery.

The buildings and street look wonderful in that render, the machinery in the foreground looks too clinical though and the sky doesn't show any gradient or variation.

It would be a good scene to experiment with the sunsky parameters.
Have a look at the abstract of a research document on the Perez Sky Model. I'm guessing the parameters a-e in this text are connected to the aconst-econst parameters in the sunsky light.

======== Abstract
Perez et al. developed a five parameter model to describe the sky luminance distribution [24]. Each parameter has a specific physical effect on the sky distribution. The parameters relate to (a) darkening or brightening of the horizon, (b) luminance gradient near the horizon, (c) relative intensity of the circumsolar region, (d) width of the circumsolar region and (e) relative backscattered light.
 

========= example sunsky

If you want really blue skies, try this:

AttributeBegin

LightSource "sunsky" "integer nsamples" [1]

            "vector sundir" [0.70000 0.400000 0.700000]

        "color L" [1.000000 1.000000 1.000000]

        "float turbidity" [2.000000]

        "float aconst" [0.500000] "float bconst" [0.500000] "float cconst" [1.000000] "float dconst" [1.000000] "float econst" [1.000000]

        "float relsize" [2.000000]

AttributeEnd
 

Quote -  Maybe I am wrong... all I know is that my computer does not seem to like all of the 

Image_Map_3

Texture "ImageMap_85" "float" "imagemap"

"string filename" ["C:UsersClayDocumentsDaz 3DStudio3ContentRuntimetexturesMorrisHiro4JMHiroLimbB.jpg"]

"float vscale" [-1.0]

"float uscale" [1.0]

"float gamma" [1]

over and over again with the only difference really being the number attached to the "ImageMap_

and when I get rid of all those and make others point to first ImageMap_85 with the file attached it works, when I leave all the others in it crashes... and now that isn't the only one that does it for, just an example of one of the images that comes up over and over again in the lxm file.

Like ADP said, Lux claims to be reusing image memory when it comes across the same image more than once. But it's possible that it stores an extra pre-processed copy for each texture that image is used in. It would then be up to the exporter to optimize what's in the lxm file.

Unfortunately, that's bagginsbill's department, and we haven't heard much from him lately. Even if he's aware of this problem, it might not be too high on his agenda, as there is still so much else to be taken care of. Maybe someone should add it to the wishlist?

Quote - > Quote - I'll post one when it finishes baking.  May be a while.  Meanwhile see link to one in my gallery.

The buildings and street look wonderful in that render, the machinery in the foreground looks too clinical though and the sky doesn't show any gradient or variation.

It would be a good scene to experiment with the sunsky parameters.
Have a look at the abstract of a research document on the Perez Sky Model. I'm guessing the parameters a-e in this text are connected to the aconst-econst parameters in the sunsky light.

======== Abstract
Perez et al. developed a five parameter model to describe the sky luminance distribution [24]. Each parameter has a specific physical effect on the sky distribution. The parameters relate to (a) darkening or brightening of the horizon, (b) luminance gradient near the horizon, (c) relative intensity of the circumsolar region, (d) width of the circumsolar region and (e) relative backscattered light.
 

========= example sunsky

If you want really blue skies, try this:

AttributeBegin

LightSource "sunsky" "integer nsamples" [1]

            "vector sundir" [0.70000 0.400000 0.700000]

        "color L" [1.000000 1.000000 1.000000]

        "float turbidity" [2.000000]

        "float aconst" [0.500000] "float bconst" [0.500000] "float cconst" [1.000000] "float dconst" [1.000000] "float econst" [1.000000]

        "float relsize" [2.000000]

AttributeEnd
 

Those settings shown here are the settings I used for the scene.  This was my first test scene, so I wasn't as picky about content, as I was about how it would work.  The one I'm rendering now is a V4 character and the subdragon.  No special posing, just testing how the exporter is handling the textures.

The only thing I can come away with is I am not sure that I will be using Firefly very much anymore!

4 hours and 2170 S/px

If I use the sunsky from above, my log says:

[2010-09-08 05:08:42 Warning: 0] Parameter 'aconst' not used

[2010-09-08 05:08:42 Warning: 0] Parameter 'bconst' not used

[2010-09-08 05:08:42 Warning: 0] Parameter 'cconst' not used

[2010-09-08 05:08:42 Warning: 0] Parameter 'dconst' not used

[2010-09-08 05:08:42 Warning: 0] Parameter 'econst' not used

[2010-09-08 05:08:42 Warning: 0] Parameter 'L' not used

[2010-09-08 05:08:42 Warning: 0] Parameter 'L' not used
 

That's strange, how about if you use sun instead of sunsky?