Luxus discussion

Slosh · April 2013

Szark said:
I am not sure what is happening with Transmaps as I had to make some windows a separate Surface zone just so the frame etc was visable. Unless Transmap are gamma correct incorrectly I have no idea.

36 S/p after 47 mins, even on my Dual Core 2 GB Ram rig using Volume I can get better s/p rate in less time. What size are you rendering. Do you have an ATI GC that can handle OpenCL The 5000 series and up I think will do it. Some Nvivda cards have it to. I try to use Hybrid rendering every time.

And some adjusting of textures maybe be required, never assume they won't need it.

My doc is 1000 x 800... Didn't realize I was going that large. I'm at 1:12 right now with only 54.73 S/p. My PC is dual core, 4 gigs RAM, not OpenCL compatible.

MarcCCTx · April 2013

Is there a list of what each of the settings in the DS Render settings does? I went to the Wiki and you could sort of hunt down individual settingss, but I didn't see anything specific to DS.

I hate just randomly changing things with the long render times.

Kerya · April 2013

http://www.luxrender.net/wiki/LuxRender_Render_settings
They are not specific to DS, they are specific to Luxrender ...

Szark · April 2013

Are you wanting Lux or Daz Studio Render settings? Lux settings see the Lux Wiki or ask here.

Joe Cotter · April 2013

MarcCCTx said:
Is there a list of what each of the settings in the DS Render settings does? I went to the Wiki and you could sort of hunt down individual settingss, but I didn't see anything specific to DS.
I hate just randomly changing things with the long render times.

Once the image leaves DS and gets passed off to the renderer, DS plays no role in rendering or render time. Before it gets passed off, anything regarding rendering is just a collection of settings to get passed off to the render engine, so there are no 'DS specific settings' per se... The are like partners with totally different tasks.

As to the issue of randomly changing things, I feel for you there. The only solution really is to do research on the way the render engine works, thus the links to the Lux render engine wiki. Other options do help though, like searching YouTube and other places for information on Lux. One has to understand how the render engine itself works if one hopes to effect aspects of the render.

Slosh · April 2013

Ok, I figured it out. To get my hair to look right, I did NOT change it to a Lux material. The solution sounds counter-intuitive to everything we've been taught, but it works! I doubled the strengths of my diffuse (after changing to pale gray 192:192:192), my opacity, and my bump. In this hair product, that meant 200% for diffuse and opacity, and 0.60 for bump. Of course, you have to turn off limits in the parameter settings for these sliders.

See for yourself: this render is with all of the gammas set to 2.2 and the diffuse, opacity, and bump strengths doubled.

Joe Cotter · April 2013

Thanks, that gives me a solution while I explore other options at least :)

Slosh · April 2013

RAMWolff said:
Mercedesk said:
I finally got a chance to really give Luxus ago... and here are the results.

Beautiful render! :-)

I second that! It jumped out at me, so clear and well lit.

SimonJM · April 2013

KickAir 8P said:
Sorry everybody, I've had some semi-minor RealLife™ issues keeping me off of the forums since last Tuesday. But my new ram's been installed, all 16 gig of it (which turned into a story in itself), and last night I luxrendered the slightly reworked version of my scene (changed a couple of textures, nothing that should affect render-time). Immense difference! The CPU was routinely maxed throughout, the ram usage never went over 10 gig, and in a bit less than ten hours I got to 160 S/p! Below is a screenshot and the untouched render, and I've got the final version up in my deviantART gallery here. I'm so happy with how this came out, it's just what I was going for -- thanks again, people!

Good to hear - happy (and relieved!) it worked for you :)

SphericLabs · April 2013

The opacity maps are currently getting the gamma value.

1) arguably this is correct in that the opacity map the artist saved was almost for sure saved in sRGB space(gamma applied). The shade of gray will not be the same gray the artist saw, unless it gets gamma corrected. Thus why Luxus currently gamma corrects opacity maps.

2) arguably this is incorrect since usually the artist is not looking at a particular shade of gray, but looking at the numerical values (128, 128, 128) when crating an opacity map. Thus indicating Luxus is wrong in applying gamma to opacity maps.

The next update will go with #2 philosophy. Meaning it won't gamma the opacity map, or any map that is usually created where the artist is usually looking at the values as opposed to to looking at the color.

cwichura · April 2013

#2 is generally correct for bump, normal, displacement, and opacity. These maps are almost always in linear grayscale.

Mattymanx · April 2013

MarcCCTx said:
Is there a list of what each of the settings in the DS Render settings does? I went to the Wiki and you could sort of hunt down individual settingss, but I didn't see anything specific to DS.
I hate just randomly changing things with the long render times.

Try the settings I listed here - http://www.daz3d.com/forums/discussion/18543/P885/#284599

But the list in the Wiki does explain what the ones listed in DS do since they are relevant to Lux Render.

Slosh · April 2013

Ok, just in case anyone is interested, I set my render going and then went to bed. This morning (after 7 hours or so), this is what I got. Only a little contrast adjustment in Photoshop for post. This image is with all of the gamma settings at 2.2, but the opacity, diffuse, and bump strengths of the hair doubled to 200% (or .60 in the case of the bump). I did not do any such doubling to the Aiko's skin or her clothing, which has the Luxus Shader "Silk Charmeuse" applied. Until Spherical gets a chance to set Luxus to ignore graytone maps, this is the transparence and bump solution I am going to go with.

glaseye · April 2013

Trying out some light- and material settings

Character is Candace for S5
used the HSS shaders, but also added one of the skin presets from UberSurface2. I'm not sure though if Luxus can/will make use of the additional US2 settings for translation to Luxrender..... a few manual tweaks were done (eyes, clothing, jewelry)
(Guess I'm gonna study a bit more on the settings Hellboy mentioned; do not yet know all the stuff he mentions, but that can be learned....)

Totally messed up the material settings on the jewelry :lol:

rendered to ca. 1000 S/p

KickAir 8P · April 2013

Settings are all out of the box, single distant light as "sun sky2" (at a rather improbable straight-shot for sunlight, hence the title), 1600x2000px , ran it almost hours 8 last night, 606.18 S/p! And it's still running, I'll see if it's improved any when I get home tonight. Pics below, for the lighter one the Kernel's set on Auto Linear, for the darker one Linear with the Estimate button hit. I combined them in GIMP with a bit more postwork, finished version in my deviantART gallery here.

jax_512b7aea09 · April 2013

I've been having trouble rendering a scene. It's an outdoor scene with a lot of high polygon trees, etc.

Whenever I try to render it, LuxRender stops, saying there is a syntax error and giving the line number.

I had to find an editor that would read the file, as it is over 2GB file size. The line LuxRender says has a syntax error contains mesh data; it's very long but I can't see any irregularities in the line.

I've tried rendering all the objects in the scene and everything renders fine by itself. I can get the scene to render by hiding some of the high poly objects, but can't narrow it down to specific objects that are problematic. If, say, I hide 5 trees it will render - but unhide those and hide 5 different trees and it will render as well. It seems like it just reaches a point where something in the process breaks down.

Perhaps all the data being lumped into one file is creating a file too large for LuxRender to parse correctly?

Soto · April 2013

KickAir 8P said:
Settings are all out of the box, single distant light as "sun sky2" (at a rather improbable straight-shot for sunlight, hence the title), 1600x2000px , ran it almost hours 8 last night, 606.18 S/p! And it's still running, I'll see if it's improved any when I get home tonight. Pics below, for the lighter one the Kernel's set on Auto Linear, for the darker one Linear with the Estimate button hit. I combined them in GIMP with a bit more postwork, finished version in my deviantART gallery here.

I recommend avoiding Auto Linear and Estimate Settings.
Estimate Settings is good to get a base for your adjustments, especially on the first seconds/minutes of rendering, but you will get better results setting the Tone Mapping options yourself while rendering, and you wont need to combine them in GIMP later either.

Jim_1831252 · April 2013

Skin is hard. It's all hard really. Head scratching fun!

SphericLabs · April 2013

Mordur said:
I've been having trouble rendering a scene. It's an outdoor scene with a lot of high polygon trees, etc.
Whenever I try to render it, LuxRender stops, saying there is a syntax error and giving the line number.

I had to find an editor that would read the file, as it is over 2GB file size. The line LuxRender says has a syntax error contains mesh data; it's very long but I can't see any irregularities in the line.

I've tried rendering all the objects in the scene and everything renders fine by itself. I can get the scene to render by hiding some of the high poly objects, but can't narrow it down to specific objects that are problematic. If, say, I hide 5 trees it will render - but unhide those and hide 5 different trees and it will render as well. It seems like it just reaches a point where something in the process breaks down.

Perhaps all the data being lumped into one file is creating a file too large for LuxRender to parse correctly?

Wow, that is a big file. Are you on a 32 bit machine?

jax_512b7aea09 · April 2013

SphericLabs said:
Mordur said:
I've been having trouble rendering a scene. It's an outdoor scene with a lot of high polygon trees, etc.
Whenever I try to render it, LuxRender stops, saying there is a syntax error and giving the line number.

I had to find an editor that would read the file, as it is over 2GB file size. The line LuxRender says has a syntax error contains mesh data; it's very long but I can't see any irregularities in the line.

I've tried rendering all the objects in the scene and everything renders fine by itself. I can get the scene to render by hiding some of the high poly objects, but can't narrow it down to specific objects that are problematic. If, say, I hide 5 trees it will render - but unhide those and hide 5 different trees and it will render as well. It seems like it just reaches a point where something in the process breaks down.

Perhaps all the data being lumped into one file is creating a file too large for LuxRender to parse correctly?

Wow, that is a big file. Are you on a 32 bit machine?
No, it's an i7 3770K with 32GB of RAM. All my software is 64bit (when available).

Like I said, the scene has a lot of high poly objects in it; I was trying to push the limits beyond what I would normally try to render.

SphericLabs · April 2013

I am guessing then its my fault. Let me look into it.

cwichura · April 2013

Does Luxus have an option to write binary plymesh files for all the geometry in the scene? Or does it only inline the geometry directly in the scene file? Not only do inline meshes make it hard to edit the scene file due to unwieldy size, they also take Lux considerably longer to parse and are wicked evil if you're doing network rendering in Lux, since it can't send the geometry and have it cached on the slave nodes for when you're iterating over test renders tweaking material settings.

My average scene export from Reality has 200MB+ of binary plymesh files. I'd hate to think how big the scene file would be if that was all inline ASCII mesh data...

SphericLabs · April 2013

cwichura said:
Does Luxus have an option to write binary plymesh files for all the geometry in the scene?
Luxus currently(1.0.0.4) takes the one file approach. Somtimes simple is better.

cwichura said:
Or does it only inline the geometry directly in the scene file? Not only do inline meshes make it hard to edit the scene file due to unwieldy size,
You should consider a more powerful text editor. I mean this in earnest.

they also take Lux considerably longer to parse and are wicked evil if you're doing network rendering in Lux, since it can't send the geometry and have it cached on the slave nodes for when you're iterating over test renders tweaking material settings.

With current CPU's these days, text parsing can be made almost as fast as binary. I expect this is causing Luxus users some slowdown at startup, but without looking at hard numbers, I doubt it even compares to the time it takes to load the huge jpegs normally seen in this field. When compared to the time to render, then it's just not that important.

My average scene export from Reality has 200MB+ of binary plymesh files. I'd hate to think how big the scene file would be if that was all inline ASCII mesh data... I think Luxus' users are managing, but the plan is to continue to improve Luxus. Also, I don't think ply meshes are compressed. So 4 bytes per float for plymesh. Sometimes a float in ascii is 2 bytes(a space and a 1 or 0) or sometimes more, but I suspect it averages out to be about the same as far as size.

SphericLabs · April 2013

Mordur said:
SphericLabs said:
Mordur said:
I've been having trouble rendering a scene. It's an outdoor scene with a lot of high polygon trees, etc.
Whenever I try to render it, LuxRender stops, saying there is a syntax error and giving the line number.

I had to find an editor that would read the file, as it is over 2GB file size. The line LuxRender says has a syntax error contains mesh data; it's very long but I can't see any irregularities in the line.

I've tried rendering all the objects in the scene and everything renders fine by itself. I can get the scene to render by hiding some of the high poly objects, but can't narrow it down to specific objects that are problematic. If, say, I hide 5 trees it will render - but unhide those and hide 5 different trees and it will render as well. It seems like it just reaches a point where something in the process breaks down.

Perhaps all the data being lumped into one file is creating a file too large for LuxRender to parse correctly?

Wow, that is a big file. Are you on a 32 bit machine?

No, it's an i7 3770K with 32GB of RAM. All my software is 64bit (when available).

Like I said, the scene has a lot of high poly objects in it; I was trying to push the limits beyond what I would normally try to render.

Mordur, If you really want to push the limits, then instancing should allow you to put in huge amounts of geometry. Luxus sends DAZ Studio instancing to LuxRender as instances.

cwichura · April 2013

SphericLabs said:
You should consider a more powerful text editor. I mean this in earnest.
I use Notepad++, personally, which is plenty powerful. (Note that I am not the one that original asked about an error during parsing and was having trouble opening the scene file in a text editor.) But text files hundreds of MB in size still require a lot of jumping around in if Luxus is intermixing material definitions with mesh definitions. (Please excuse my ignorance, as I haven't used Luxus, so I don't know if it does, or if it writes all the materials first and then all the geometry after that.)
SphericLabs said:
cwichura said:

they also take Lux considerably longer to parse and are wicked evil if you're doing network rendering in Lux, since it can't send the geometry and have it cached on the slave nodes for when you're iterating over test renders tweaking material settings.

With current CPU's these days, text parsing can be made almost as fast as binary. I expect this is causing Luxus users some slowdown at startup, but without looking at hard numbers, I doubt it even compares to the time it takes to load the huge jpegs normally seen in this field. When compared to the time to render, then it's just not that important.

That still doesn't address the issue of network rendering being unable to cache any of the mesh data if its inline in the scene file. On the weekends, for example, I VPN in from home to do network rendering, and sending several hundred MB of mesh data takes 20+ minutes to upload. But once it's uploaded, I can restart Lux almost as fast as if I wasn't using the network slaves at all. But with Luxus including all the mesh data inline, that would require the 20+ minutes to upload every time, even if none of the geometry had changed because only material definitions are being tweaked.

Also, I don't think ply meshes are compressed. So 4 bytes per float for plymesh. Sometimes a float in ascii is 2 bytes(a space and a 1 or 0) or sometimes more, but I suspect it averages out to be about the same as far as size.
This again has an impact for network rendering. One of the things on LordCRC's short list for Lux's network code is to compress all files it sends to slave nodes. But the scene file itself (and hence any inline ASCII meshes) will not be compressed; only cacheable objects will be.

SphericLabs · April 2013

I will certainly look into this for network rendering sake, but you are only the second person to even mention that they use it in their workflow.

cwichura · April 2013

Network rendering is one of Lux's big advantages. Because of it, I can get many renders done in <24 hours of real world time, rather than taking a week. (And I'm using multiple fast i7 machines -- I render at moderately high resolutions and moderately complex scenes with anywhere from 3.5-10mil tris after subdivision.)</p>

kittenwylde · April 2013

As soon as I get off my lazy behind and get my network set up again, I'll be joining in the network rendering crowd. My main machine's awesome, true, but there's just something neat about having a tiny little render farm all of my own. :)

KickAir 8P · April 2013

Hellboy said:
KickAir 8P said:
Settings are all out of the box, single distant light as "sun sky2" (at a rather improbable straight-shot for sunlight, hence the title), 1600x2000px , ran it almost hours 8 last night, 606.18 S/p! And it's still running, I'll see if it's improved any when I get home tonight. Pics below, for the lighter one the Kernel's set on Auto Linear, for the darker one Linear with the Estimate button hit. I combined them in GIMP with a bit more postwork, finished version in my deviantART gallery here.

I recommend avoiding Auto Linear and Estimate Settings. Estimate Settings is good to get a base for your adjustments, especially on the first seconds/minutes of rendering, but you will get better results setting the Tone Mapping options yourself while rendering, and you wont need to combine them in GIMP later either.
Uh-uh -- you will get better results setting the Tone Mapping options yourself while rendering. I will get lighting more suitable to anywhere from surreal alien landscapes to the pits of Hell than the doorway of an ordinary pub on a sunny morning. :red: Appreciate the thought, but I'm not there yet.

Speaking of there, after I got home from work I stopped the render a few seconds after 18 hours, at 1.40k S/p -- no visible difference between that and what I had at at 600 S/p, and even GIMP's Difference Mode only found a faint dusting. So, that worked out well. :coolsmile:

InaneGlory · April 2013

KickAir 8P said:
Hellboy said:
KickAir 8P said:
Settings are all out of the box, single distant light as "sun sky2" (at a rather improbable straight-shot for sunlight, hence the title), 1600x2000px , ran it almost hours 8 last night, 606.18 S/p! And it's still running, I'll see if it's improved any when I get home tonight. Pics below, for the lighter one the Kernel's set on Auto Linear, for the darker one Linear with the Estimate button hit. I combined them in GIMP with a bit more postwork, finished version in my deviantART gallery here.

I recommend avoiding Auto Linear and Estimate Settings. Estimate Settings is good to get a base for your adjustments, especially on the first seconds/minutes of rendering, but you will get better results setting the Tone Mapping options yourself while rendering, and you wont need to combine them in GIMP later either.

Uh-uh -- you will get better results setting the Tone Mapping options yourself while rendering. I will get lighting more suitable to anywhere from surreal alien landscapes to the pits of Hell than the doorway of an ordinary pub on a sunny morning. :red: Appreciate the thought, but I'm not there yet.

Speaking of there, after I got home from work I stopped the render a few seconds after 18 hours, at 1.40k S/p -- no visible difference between that and what I had at at 600 S/p, and even GIMP's Difference Mode only found a faint dusting. So, that worked out well. :coolsmile:

Try this. Select Linear. Set your ISO to 1000, Shutter to 1/60, F-Stop to 8

Is you picture to dark or to light?

If it's to dark lower the F-Stop one level (stick with using the numbers on the pull-down menus). Each level (or 'step') you lower (decreasing the number) the F-Stop doubles the light in your scene. Increasing the F-Stop halves the light. If your lucky you'll find a F-Stop that's just perfect but more than likely you'll find one that is to dark while the next is to light.

Then switch to the Shutter. Lowering the Shutter speed (1/60 to 1/30) increases the light hitting the camera, Increasing the speed (1/60 to 1/125) decreases the light. I don't remember the math correctly right now but step in shutter speed is less drastic than a change in F-Stop.

If it's still not exactly what you want switch to ISO. Higher numbers mean lighter scenes, lower will give you darker. Once again each step in ISO is less harsh than a step change in Shutter Speed.

Hope that helps

Notifications

Luxus discussion

Comments

Adding to Cart…