Quote - > Quote - I didn't mean to insinuate that most Poser users aren't strong in the gray matter department, but there are always a few who make the rest of us look bad...lol.

Crowd dynamics mixed with individual laziness. Individually taken we're all intelligent and nice, as a crowd we're just sheep. :-/

Anyway, to get back to the point, we have a new information, like, really breaking news from today September, 16th: The shading problem of Lux isn't fixable (I guess "in the next two versions"); Which means LuxPose has a chance to anticipate this and implement a workaround, before the reality crowd even notices that bug exists... evil gin

If we want, that is.

wonders quietly if the underlying problem might be quads or at least made worse by them - the weird shading problem...

Laurie

The terminator artifact is there because the shading normal is different from the geometry normal.
Lux is asked to do the impossible by rendering something flat but making it look as if it were curved. It's doing its best to approximate that by using Phong interpolated normals (which are far from being physically correct), and in most cases it works, but in cases like this it shows up at the shadow terminator.

(Which is why in my opinion, all the "physically correct" renderers are false advertising: polygons are flat, and if you were to look at a polygonal model in real life, it would appear faceted, not smooth. When a renderer makes flat polygons look smooth, in my book that's make-belief and not physics.)

Quote - (Which is why in my opinion, all the "physically correct" renderers are false advertising:

"Physically correct" people think that light are photons, but ignore that light is a wave, even time to time they speak about Fresnel, but have no idea what is characteristic impedance only knowing  the photon's index of refraction.
Does one of the keystone of  "physically correct", the Helmoltz reciprocity is obeyed in our day life experience with a common window's glass?
Micheangello didn't care if his painting were physically correct or not, if you look up the dome you see the angels floating above and for you the angels are real even there are no angels in the 3d dome volume.
If Poser produce a nice rendering is fine and if Lux produce a nice rendering is also fine.

So, just a question here about Luxrender glass material. It's reflection value is set? You can't turn down the amount of reflection of it?

I think lowering the Kr numbers lowers the amount of reflection for that color.

So "color Kr" [1.0 1.0 1.0] will be a bright white reflection
"color Kr" [0 0.1 0] will give a little bit of green reflection

Attached Link: LuxRender materials wiki

Any how, the wiki on LuxRender recommends that you lower both Kr and Kt (I think that's what the other one was anyway) and to make sure that they are roughly the same color so that reflection and transmission properties don't skew too heavily. Otherwise, pure white (1.0, 1,0, 1.0) is okay. Also, you may want to set the index of refraction to a different type for other glass effects. I think the link to a massive list was posted a bit earlier and should prove helpful.

And, am I seeing things or did part of the glass do a "ding" with the light? Lol, it's a really cool effect!

Quote - The terminator artifact is there because the shading normal is different from the geometry normal.
Lux is asked to do the impossible by rendering something flat but making it look as if it were curved. It's doing its best to approximate that by using Phong interpolated normals (which are far from being physically correct), and in most cases it works, but in cases like this it shows up at the shadow terminator.

(Which is why in my opinion, all the "physically correct" renderers are false advertising: polygons are flat, and if you were to look at a polygonal model in real life, it would appear faceted, not smooth. When a renderer makes flat polygons look smooth, in my book that's make-belief and not physics.)but still it shouldnt happen.

i used a very high poly ball and used the sun and it still showed artifacts. its a huge bug and they will need to fix it because other raytraced  renders dont have this.

Quote - Ok, I've been thinking hard the last day or two... Get ready - let's see if I can explain this in a way that makes sense...lol:

I've been pondering the obvious discrepancy between Poser, that can't handle extremely poly-heavy scenes and Luxrender, that loves high poly and can handle them fine. So I was thinking: could it be possible to have a low res placeholder in Poser and somehow swap it out for a high res version during the exporting process? I know I'm probably asking a whole lot. And it wouldn't solve anything for current content, only future content if it was possible. But I was thinking how nice that would be if we could do that. Set the scene up with low poly things in Poser and grab the high poly versions at export ;o). I added it to the wishlist btw. I can dream...lol.

Laurie

but Luarie look at Bagginsbills render. this is a high poly female figure. you can not subdivide this figure and everything in the scene to get rid of an artifact that should nto be in the software in 2010.
i think they will fix this in 1 or 2 months. other raytraced renders dont have this. this is 2010 this should not happen.
everyone needs to read this. this has nothing to do with Poser. it has ntohing to do with the geometry exporter. i am using Blender and i get the same artifacts.

Bagginsbill i think you should go work for ILM or Weta and create for them the ultimate raytracer(render) that can be used for movie production and for me hehehehehheeheheh ;) 

Yes, there is a light spark there on the back edge of the vase (which I modeled myself in Hexagon a year ago). That spark only appeared just before I stopped the render after 3 and a half hours. I copied the glass material from one of Laurie's posts. I do know it is set to pure white. I think the IOR is 1.5.

Quote - > Quote - bagginsbill can you show an example of a skin render in a close up?  i just want to see how it looks in a close up.

a demo render will give me more strength to wait.

thanks.

I didn't spend any time fixing this - just rendered. I have no good eye textures - this was the only one I could find without burned-in specular and it is terrible. Also, V4 eye geometry is terrible. Just ignore the eyes.
.

interesting render.

since this is a raytraced render  we will not be able to do all the hecks like in the VSS shader right? remember there you added a red tint around the Blinn shader. it really brought the skin to life in the shadows and cheated a little SSS.

here we will not be able to do it right?

Quote -
To put it bluntly, the tests rg5a did (and posted in the Lux forum) were done with whatever subdivision LuxPose is capable of right now (23a), so it is clearly very far from being enough.

I'm a bit surprised by this statement. The subdivision level can be set as high as you like, if you have the time and hard disk space for it. I'm not sure if the GUI supports that, but it can be set in dataOut.bbml. If there's a geometry that shows these artifacts no matter how much it gets subdivided, I'd very much like to see that.

At any rate, Luxrender can do its own subdivision, which is clearly the better solution, except for one thing: because of the way texture coordinates are handled, we have to cut the mesh apart at texture seams and material boundaries. There's no way of telling Lux that these are no real boundaries, so when subdividing, it will produce creases and even pull the mesh apart at these seams. Doing the subdivision in the exporter is a workaround for this problem.

However, unlike the shading problems, the way Lux treats texture coordinates and normals can be fixed quite easily, and the developers seem to realize that there's a real need for doing that. I've seen concrete suggestions for fixes in the forums, but obviously I don't know how soon we can expect to see them implemented.

ice-boy you seem to be missing some very important points about LuxRender.

1. it's free.
2. the guys writing it aren't getting paid to do it.
3. it's still in the alpha stages way behind other render engines.
4. Poser content is generally low poly & designed for Poser (& DS).

No-one should be surprised that Poser content doesn't look it's best when rendered in LuxRender without some serious tweaking.

ps a new build of Firefox seems to have fixed the posting bug from yesterday for me.

Quote -
I'm also thinking about a selective subdivision, based on the normal of the polygon with respect to light sources. It would be pretty easy I think to decide which polygons are near a terminator and handle them differently. I'm not familiar with SubD algorithms, though, so odf would need to comment.

I don't know all that much about selective subdivision algorithms, except that they exist. :laugh:

That said, here are some thoughts on the matter:

1) I don't think looking for terminators is the way to go. First of all, they are just the most obvious places where the shading goes wrong because of 'large' polygons. But like stewer said, wherever you try to shade a flat polygon as if it were curved, you get a problem. So it seems to me that selective subdivision should be based on the angles between adjacent polygons. If the angle is too 'sharp' - i.e., too far away from 180 degree - then these polygons should be subdivided and the angle smoothed out.

Second of all, a selective subdivision that is independent of lighting would allow us to export the geometry once and then just play with the lighting without having to wait for the subdivision to complete each time. The meshes produced could also be exported to other software.

1. As I said, I don't really have a solid knowledge of these things, but I'm pretty sure Loop subdivision (what Lux uses internally) is better fitted to selective methods than Catmull-Clark (what I'm using in the exporter). I don't know the exact formulas for Loop subdivision, just the general scheme (one triangle turns into four smaller triangles). But it shouldn't be too hard to find references.

Anyway, interesting idea. I'd almost be inclined to do it just for the heck of it, because that's how I'm wired. :lol:

Poser content is not low polygon.

A renderer should be able to render curved areas, all other renderers that I have heard of can.

Quote - Poser content is not low polygon.

A renderer should be able to render curved areas, all other renderers that I have heard of can.

Depends what you call low poly I suppose, anyway as I said before LuxRender is still early in it's development stage & we can expect problems like this to show up from time to time, it will be fixed.

The shadow termination problem affects all current unbiased renderers(including Maxwell, Fryrender, Octane etc), so I don't think it will be fixed.

are you sure that all other unbuased raytracers have this?

You also get it in Vue (admittedly a biased render engine but the principle is the same) and I think you also get it in MentalRay although I haven't done a render that would provoke it for a while.

it's known as "The Terminator Problem" and has been known about since 1987.

research.microsoft.com/en-us/um/people/johnsny/Caltech/p119-snyder.pdf

page 121 explains whats happening.

Quote - it's known as "The Terminator Problem" and has been known about since 1987.

research.microsoft.com/en-us/um/people/johnsny/Caltech/p119-snyder.pdf

page 121 explains whats happening.

I'm sorry in advance for this..

Damn that Schwartzenegger he gets everywhere. :lol:

Wow! I killed the thread! is everyone hibernating?

Quote - Here, have some hair to pass the time!

Checkerboard hair. My favorite style ;o).

Lucifer - it typicially gets pretty dead around the RO forums on the weekends, especially while the weather is still cooperating. When it starts to get cold, then more ppl will be hanging around weekends...hehe. Except odf and others from down under and south of the equator. Their nicer weather will just be getting started ;o). I am SO jealous...lol.

Laurie

If anyone's interested I posted a "recipe" for the old-style greenish blue glass that you see in old botles and windows on the LuxPose Project Help Wiki page.

yay

Laurie

Um, who wanted the wiki pages for the lights and materials? LOL

C'mon people...wiki-up and help your fellow LuxPose-r! ;o)

Materials
Lights

Laurie

Quote - Um, who wanted the wiki pages for the lights and materials? LOL

C'mon people...wiki-up and help your fellow LuxPose-r! ;o)

Materials
Lights

Laurie

Seems you are the only one able to sort out useful materials, Laurie.

I did lots of example renders the last few days, but mostly with light. My feeling is that we have way too mutch "light energy" in LuxPose. Lower the gain of all lights results in better renders. At least for me.

Quote - Seems you are the only one able to sort out useful materials, Laurie.

I did lots of example renders the last few days, but mostly with light. My feeling is that we have way too mutch "light energy" in LuxPose. Lower the gain of all lights results in better renders. At least for me.

If that's the case, then maybe you should load up the light wiki page adp....lolol ;o). And as far as materials are concerned, I'm sure bb has a much better grasp than I do. I've just been playing...hehe.

Laurie

Quote - Here, have some hair to pass the time!

Nice, odf! Brings a whole new meaning to the term "hairball." :biggrin:

I think we're not using enough light.

Questions for thought:

On a sunny day in clear skies, what is the EV in real life. What is it after exporting Sun+Sky in Luxpose at the moment, starting with a 100% infinite light? How about 200%? How about 400%?

On such a day, how do you set up your real-life camera for a good exposure? Is that what you're using in Lux as well, or is there not enough light to do that?

Some background info:

http://en.wikipedia.org/wiki/Sunny_16_rule

Quote - > Quote -

To put it bluntly, the tests rg5a did (and posted in the Lux forum) were done with whatever subdivision LuxPose is capable of right now (23a), so it is clearly very far from being enough.

I'm a bit surprised by this statement. The subdivision level can be set as high as you like, if you have the time and hard disk space for it. I'm not sure if the GUI supports that, but it can be set in dataOut.bbml.

Well, if the level of subdivision can already be set as high as we want, then everything is fine, my wish was granted. I wasn't dissing, I have no idea how LuxPose does the subdivision and what it takes to get some more; If you tell me you only need to add another button, that's perfect.
(As for the validity of the workaround, that's what the Lux dev said...)

Quote - because of the way texture coordinates are handled, we have to cut the mesh apart at texture seams and material boundaries. There's no way of telling Lux that these are no real boundaries

Didn't I read something about it in the "Exporter developer's wish list for v.0.8" thread, over in the Lux forums?

Quote - I think we're not using enough light.

Questions for thought:

On a sunny day in clear skies, what is the EV in real life. What is it after exporting Sun+Sky in Luxpose at the moment, starting with a 100% infinite light? How about 200%? How about 400%?

On such a day, how do you set up your real-life camera for a good exposure? Is that what you're using in Lux as well, or is there not enough light to do that?

Some background info:

http://en.wikipedia.org/wiki/Sunny_16_rule

The Lux sun, as I use it*, is almost too strong. When I use the Lux sun very high in the sky, the scene requests (for 64 ASA sensibility) a shutter of 1/500 and an fStop of 22, which is IMHO (at least) one fStop too much. My bet would had been 1/250 and 16, 22 if the subject is bright.

• Here is my Lux sun setting, so we can compare:
  AttributeBegin
  LightSource "sunsky" "integer nsamples" [1]
          "vector sundir" [0.2 1.6 0.5]
          "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

Edit - Well, my memory doesn't seem to fit in with that Sunny 16 rule...  I might be wrong indeed, it's years since I shot any manual pictures...

Quote -

Quote - because of the way texture coordinates are handled, we have to cut the mesh apart at texture seams and material boundaries. There's no way of telling Lux that these are no real boundaries

Didn't I read something about it in the "Exporter developer's wish list for v.0.8" thread, over in the Lux forums?

I seem to remember seeing someone suggest an additional parameter to the mesh primitive, which would be a list of pairs of vertices to be 'sewn' (or 'welded', in Poser lingo) together. Unfortunately, I can't find that post at the moment. That's not an ideal solution from the point of view of exporter developers, but it looks like one that might be relatively simple to implement in Lux. So hopefully, they'll get on it soon.

Quote - > Quote -

Quote - because of the way texture coordinates are handled, we have to cut the mesh apart at texture seams and material boundaries. There's no way of telling Lux that these are no real boundaries

Didn't I read something about it in the "Exporter developer's wish list for v.0.8" thread, over in the Lux forums?

I seem to remember seeing someone suggest an additional parameter to the mesh primitive, which would be a list of pairs of vertices to be 'sewn' (or 'welded', in Poser lingo) together. Unfortunately, I can't find that post at the moment. That's not an ideal solution from the point of view of exporter developers, but it looks like one that might be relatively simple to implement in Lux. So hopefully, they'll get on it soon.

If you export the normals the solution is very simple, you only need to create extra vertices in the xported lux files, these extra vertices have the same x,y,z values, the same normal values, but different uv values and the faces at the seam boundary on one side will point to the original vertices and on the other side to the extra vertices. As you export the normals and the normals are the same for both faces for Lux it will be two welded faces even have different vertices number.
The same for different material boundaries..

Quote -
If you export the normals the solution is very simple, you only need to create extra vertices in the xported lux files, these extra vertices have the same x,y,z values, the same normal values, but different uv values and the faces at the seam boundary on one side will point to the original vertices and on the other side to the extra vertices. As you export the normals and the normals are the same for both faces for Lux it will be two welded faces even have different vertices number.
The same for different material boundaries..

That's precisely how I'm exporting right now, and it renders fine.

The problem occurs when I tell Lux to subdivide the mesh further using its built-in Loop subdivision algorithm. Because Lux does no automatic welding (as far as I know, but the discussions on the forums seem to confirm that), the subdivision algorithm will treat those vertices as different, even though they have the same positions and normals. So any texture seam or material boundary will look like a mesh boundary (not for normal rendering, mind you, only when subdividing), and as a result one gets creases and sometimes even holes.

Because of that, people are currently forced to do the subdivision in the exporters or directly in the application.

Well, this is a big problem. Subdivision deforms the mesh, it can work fine on a closed continuous two manifold surface, but if you have a discontinous surface you have the risk to have the mesh broken after the subdivision because two vertices that had originally the same value will deform in a different way.
I have experimented Catmul-Clark and loop subdivision with Victoria 4 and the result looked much worst than the original Vicky even she was all welded.
The only subdivision that has preserved her shape was middle-point that only increased the number of faces without degrading the figure.
You can ask me for what increase the number of polygons if the shape continue to be the same?
For magnets, the morphs can be more precise where you need!

Quote - Well, this is a big problem. Subdivision deforms the mesh, it can work fine on a closed continuous two manifold surface, but if you have a discontinous surface you have the risk to have the mesh broken after the subdivision because two vertices that had originally the same value will deform in a different way.
I have experimented Catmul-Clark and loop subdivision with Victoria 4 and the result looked much worst than the original Vicky even she was all welded.

I generally agree with the first part, but I'm surprised that V4 gave you any trouble when subdividing. Which parts of the mesh did not turn out well?

By the way, while preparing these examples I noticed that the subdivision level for figures is not currently (version 1-23a) passed through to pydough. Line 158 of PoserLuxExporter_workers.py reads

            
params.subdivisionlevel =
params.get("ccfigures")

which should theoretically work, but turned out to have no effect. After changing that line to

            
params["subdivisionlevel"] =
params.get("ccfigures")

subdivision worked as intended.

Quote - I generally agree with the first part, but I'm surprised that V4 gave you any trouble when subdividing. Which parts of the mesh did not turn out well?

He, he, the breast...

Sorry, I cannot see any difference between the two images.

Look at the terminator on her right shoulder from the backlight, and the shadow on her neck, right below the chin.

I see now, it's a shadows rendering difference and not a geometry difference. Don't know why it happens, it looks as if the shadows were averaged from the values at some points or vertices, smaller the polygons lesser the error in the average.

Quote - I see now, it's a shadows rendering difference and not a geometry difference. Don't know why it happens, it looks as if the shadows were averaged from the values at some points or vertices, smaller the polygons lesser the error in the average.

It's a problem of Lux and some other renderers that we've been talking about earlier (look for the posts by bagginsbill and rty on page 37, for example). Shading normals can be interpolated, but when the discrepancy between the interpolated normals and the actual polygon normals get too large, the renderer can get confused. That is quite obvious when you have a terminator (boundary between the lit and unlit side of an object), because there it's not just a question of how to shade a certain pixel, but first of all whether it receives any light from a particular light source at all.

PS: If you look closely at the outlines of the shoulders, you'll see that they are a bit smoother, too, in the subdivided version. But that alone would have hardly been worth the effort.

Quote - That is quite obvious when you have a terminator (boundary between the lit and unlit side of an object), because there it's not just a question of how to shade a certain pixel, but first of all whether it receives any light from a particular light source at all.

I found the same problem with my experimental per vertex shadows, if the surface that receive the shadow has not enough polygons the shadow becomes irregular and looks very bad. Until now I haven't found any solution.
The origin of all are the hard shadows that are not natural (light are not photons). A point is in shadow and another very near point is not in shadow, is a yes and no answer. As the shadow is proyected on some surface the size of the shadow increase with distance and a small yes or no turns into a big yes or no.
The solution would be natural shadows with a soft transition between light and darkness.

Another thing that makes me crazy are the fireflies. I am doing now a rendering of a scene, the rendering has going well and the quality was improving. After an hour I was expecting one or half hour more to have the image with good quality and then..., appeared a firefly, the scene darkened and some time later cancell the rendering, who knows how much hours will take to remove this firefly and if it will be removed. I started again the rendering from zero, it will be much faster unless something else happens. Until now are 28 minutes and all is going well.
LuxRender makes a wrong anomalous hyper bright sample and the sample is not discarded and takes an eternity to average if not summed up with another wrong sample.
And the self darkening of the image is annoying and makes useless the image to correct a single pixel in Photoshop.

Quote -
And the self darkening of the image is annoying and makes useless the image to correct a single pixel in Photoshop.

That sounds like a tonemapping problem. If you are using MaxWhite or Contrast, try switching to Linear or Reinhard.

P.S. I use Reinhard and always turn on noise reduction. GC is turned down to 1.9.

interesting render .

i myself like doing renders in LUX that are not possible in Poser.

i like to use a big square shape as a lightsource and use sky through the windows also as the lightsource.