Quote - Some wonderful material experiments Laurie, I love the pearly #20 and shiny blue metal #21.
And thank you for the sample scenes.

I haven't had any more camera problems since version 1.20 though.

I'm not even sure I have the most recent one...ain't it awful? ;o)

Laurie

Quote - Ooops, didn't open up my window enough! LaurieA, your scene is rendering like your demo pic. So sorry! Still tho don't know why my export renders wrong. I'll have to examine the Lux files in your demos. Again, thank you so much for putting them up!

You could switch to full screen view, and for me anyway the scroll wheel on my mouse zooms the render view in and out.

Poser Scene:

Holy cow...the problem others were having, but in reverse???

shakes head

;o).

Now that I look, it might have something to do with the aspect ratio. I tend to make landscape renders, which were previously getting zoomed OUT. I wonder if the fix makes portrait renders zoom in? Just a guess...lol.

Laurie

It looks the same if I export from Poser Pro also. I have not installed the exporter into Poser 7. I keep Poser versions 4 to 7 in an external drive (Yeah, you read that right, I've got all those versions with files spread out between them. The only one I consolidated was everything in Poser 6 went into Poser 7). So other people were having a problem with the camera view being pulled out too far????

That looks like a massive pointlight being in front of the camera.

Try moving your light higher, see if it is the light.

My render window in Poser8 is set up for doing 8 X 10 images for Deviant Art prints. I found the right size for doing that and I'm changing my window. When I tried my first export of a scene of a standing nekkid V4, I could tell that the camera was the same as in Poser, but there was no light or texture export. I had a white outline of her hair, face, a necklace, and her shoes at the bottom. Everything else was black. Haven't tried that export again.

Just occurred to me that my default camera is set at 100mm. Does that have something to do with it?

It might, the exporter is supposed to get the camera settings from Poser, but I also try to make sure that Poser and LuxPose are set the same.

Focal length is supported and should be usable at all values.

Check the camera "scale" - someone found that caused a change in interpretation that was not dealt with in the exporter.

I don't even get what the point of a camera "scale" is.

I have never touched the scale of the camera. I didn't think that really did anything so I've never messed with it. So the camera scales would be the Poser8 default. In Poser Pro, the main camera is set at 263%. What should I change it to? Geez, it's the same in P8. I set the camera to 100% and reset my test scene.

Try setting it to 100%.
BB, I use camera scale quite a lot, I find it's easier than zooming out and once I've finished a simple alt-click on the scale dot resets it.

Damn, I have to reset my cams. sigh

ODF- WOW.  Impressive.  :a_shocked:  This is really cool!  :m_bouncy:

   The thing that comes to mind first, though: BB mentioned that Lux's primitives are calculated entities, rather than polygons (not sure how to word that, but you probably remember what I mean)... will making each segment of hair out of polygons instead, make the files a whole lot bigger, and/or render slower?  It's probably worth the wait, either way, that's not a big concern.  :biggrin:

 Again, wow.  This is amazing.  I can't really fathom the shenanigans required for calculating this.  I'm really looking forward to trying this out!  Great job!  :thumbupboth:  

so what's a good water material?  i've tried roughglass, glass , &  laurie's toothpaste gels but none look much like water when i put them on a plane.  i know they can do it in the Plugin-That-Shall-Not-Be-Named......

Quote - so what's a good water material?  i've tried roughglass, glass , &  laurie's toothpaste gels but none look much like water when i put them on a plane.  i know they can do it in the Plugin-That-Shall-Not-Be-Named......

Well, water is about 1.3 IOR or thereabouts and I'd imagine you'd need a good bit of cauchyb in there. A flat plane isn't going to look all that great, so if you can rough it up just a little bit, that would probably make it better. Try using some of the filters that Luxrender has for the bump channel and see if that works ;o).

Laurie

Quote - Focal length is supported and should be usable at all values.

Check the camera "scale" - someone found that caused a change in interpretation that was not dealt with in the exporter.

I don't even get what the point of a camera "scale" is.

Well, I guess we should be grateful that they put scale dials in objects that they make no sense for, or otherwise we wouldn't have an easy way to set the scale for "point" lights when exporting to Lux. :laugh:

But I agree, that camera scale thing is irritating, in particular when you take into account that there's separate scaling on the x-, y- and z-axis as well.

Quote - BB mentioned that Lux's primitives are calculated entities, rather than polygons (not sure how to word that, but you probably remember what I mean)... will making each segment of hair out of polygons instead, make the files a whole lot bigger, and/or render slower?

That's really hard to guess, but I expect it's not going to be as bad as you might think.

Let's talk about the files sizes first:

LuxBlend instantiates a cylinder object for each hair segment and a sphere object for each joint. That means two transformation matrices, each of which consists of 16 floating point numbers, plus all the extra text around them to set things up properly. In contrast, the mesh version uses 15 floating point numbers (5 vertices with 3 coordinates each) for each joint and each end, plus 20 integers for each segment and 5 for each end to specify the polygons. So very roughly, that's 32 numbers plus a whole bunch of big words like "ObjectInstance" and "TransformationBegin" for LuxBlend, compared to 35 numbers and none of the big words for us. That does not sound like the our files will be getting a whole lot bigger at all.

As for rendering speeds, I don't know Luxrender's internal workings well enough even to make an educated guess. But remember that BB was talking about lights when he stated that meshes objects are slower than primitives. That's a whole different ballpark. Lux works very, very well with insane numbers of mesh polygons in regular objects (I think the record is a trillion for a single render). I'm not even sure it would handle large numbers of primitives as efficiently, since I would expect that the developers would have concentrated on optimizing the handling of meshes. In addition, I've seen it stated that the instantiation itself slows things down. So a priori, I see no reason why the mesh version should be considerably slower than what LuxBlend does, either.

Finally, in every discussion I find over at the LuxRender forum, I see people stating that the proper way to convert hair should be in mesh form, and point out the shortcomings of the cylinder/sphere approach (visible joints, no UVs, etc). So I decided there was no point in even going that way.

Quote - So very roughly, that's 32 numbers plus a whole bunch of big words like "ObjectInstance" and "TransformationBegin" for LuxBlend, compared to 35 numbers and none of the big words for us. That does not sound like the our files will be getting a whole lot bigger at all.

   You're right, that doesn't sound too bad... well, comparatively.  :tongue2:  When I was looking at the LuxBlend output, I was marveling at how many lines it took to describe hair... can't get around that.  I'm not sure how Poser gets away with just recording vertices, but if you make the hairs really thick, the segments look like flat planes, always facing the camera... I think it's faking it two-dimensionally on the fly.  For shame (but clever!).  Polys are much more straightforward.  :laugh:

 So yeah, this sounds great, I'm psyched.    :biggrin:

Ugh! The Poser API for dynamic hair looks even weirder than what I've been dealing with before. Correct me someone if I'm wrong: 

• If the IsHairProp() method of an actor returns 1, that tells me that the "polygons" in that actor's geometry are really meant to be poly-lines, and each line describes an individual hair.

• So far so good, but now I want to know how thick I need to make those hairs. For that I need to find the parent actor of my hair prop, looks through its hair groups and identify the one with the same name as the prop I'm currently working with. That hair group has methods RootWidth() and TipWidth() which should give me the information I need.

• Last step: what darn unit are those hair widths in? Does anyone happen to know or feel inclined to find out? A hair of width 1 is pretty darn thin, so it's none of Poser's usual units.

Hair ball created in Poser and rendered in Lux. The export rate was 40000 hair segments in 25 seconds on my machine (or 2000 hairs at 20 segments each) with the first version of the code. At the moment, the hairs have constant width and no UVs (or more to the point, no Vs, I guess), but I'll change that.

The file size is 27 Megabytes.

Looking good ODF, think the ball needs a haircut though. ;)

Well, you make me one that's better groomed, and I'll render it. :lol:

If you want to render dynamic hair you need an engine that is able to render lines, if you want to render particles you need an engine that is able to render points.

Here we go again.

kawecki - do you know that the English word "need" means "must have" "cannot do without" "is a requirement with no workaround"?

And that you make these statements directly in the face of contradictory evidence? Did you even look at odf's picture above? What are you a professional troll?

Quote - At the moment, the hairs have constant width and no UVs (or more to the point, no Vs, I guess), but I'll change that.

I need to preface my post here with the acknowledgement that I'm not totally clear on hair in Poser. Having said that...:

I think Poser hair has U, V, W, coordinates, and what you mention as V is actually W.

The U, V seem to be a constant for each hair and comes from the UV of the surface upon which the hair was grown. I use this fact to produce color patterns in the hair, particularly when used as fur.

The W value has traditionally not been accessible to Poser users in the mat room, except by the use of the "Hair" material room node. However, I recently posted a method of arranging nodes that permits us to directly use the W value for shading purposes. I don't think you need to see that, just be aware that it exists.

To match the shading behavior of Poser hair, it will be desirable to find all three coordinates and somehow provide that info in the exported hair. I believe that Lux supports not just UV but also ST coordinates. You may need to make use of that.

Ah, thanks bagginsbill! I wasn't aware of that.

Proof of the W coordinate in hair and how to use it is here:

http://www.renderosity.com/mod/forumpro/showthread.php?thread_id=2807241

Very cool!

Well, having three coordinates makes much more sense, anyway. Thanks for the tip!

Arguably, 4 coordinates could/should be supplied, the fourth being where you are around the hair cross section. I can imagine some hair shading algorithms that would want to know all four values.

Quote - So, the unit for hair width in Poser seems to be 0.0002 units or approximately 0.02 inches (0.5mm). Here's what I get in Lux based on this value, with Poser's default root width of 1.0 and tip width of 0.4.

Excellent.

Whoops - I mean - IMPOSSIBLE.

You need a renderer that renders lines. What you're doing is nonsense. Stop showing fake renders. grin

Quote - Arguably, 4 coordinates could/should be supplied, the fourth being where you are around the hair cross section. I can imagine some hair shading algorithms that would want to know all four values.

That could be done quite easily, in fact. I'll put it on my to-do list.

Quote - > Quote - So, the unit for hair width in Poser seems to be 0.0002 units or approximately 0.02 inches (0.5mm). Here's what I get in Lux based on this value, with Poser's default root width of 1.0 and tip width of 0.4.

Excellent.

Thank you, good Sir! I'm actually a little proud at how I compute the hair mesh. At first sight one would think that lots of line intersections needed to be computed. But in fact one simply constructs the cross section at the base and then shifts it along the polyline by projecting onto the plane normal to the bisector of the consecutive line vectors at each joint.

Quote -
Whoops - I mean - IMPOSSIBLE.

You need a renderer that renders lines. What you're doing is nonsense. Stop showing fake renders. grin

I thought he was using "need" as in "I need new shoes".

Damn, that impossible hair looks pretty good ;o). I guess we'll need an invisible brush to go with it...lol.

Laurie

So, I had a little play in the Python console within Poser, after realizing that (a) I can dock that darn thing and (b) it behaves much less erratic then.

Anyway, here's what I think Poser's API tells me about texture coordinates for hairs: the first vertex of each hair has both U and V set, which seem to be the texture coordinates for the point on the parent surface that the hair grows from. The remaining vertices all have U = 0, and V steadily increasing until at the final vertex it reaches 1. So that seems to be the W that bagginsbill mentioned.

Unfortunately, Lux will not understand that kind of encoding, so all four coordinates will have to be provided for each vertex on the hair mesh. For 'hair' that's so thick that faceting could become a problem, I'll also add the normals for each vertex. All this data is straightforward to extract and shouldn't slow down the exporter much. But I'll make it optional, anyway, in the pydough library, so that users can opt for smaller lxo files when they don't need the extra stuff.

Quote - I believe that Lux supports not just UV but also ST coordinates. You may need to make use of that.

Hmm, the only reference to ST coordinates I could find is in the description of the trianglemesh shape type in the wiki. All the other shape types (including mesh) don't seem to have that parameter, or at least it's not documented. So I'm beginning to wonder if STs are something we could actually make use of. Have you seen any indications that they are actively supported?

Well, I guess I'll add the option to include the data, anyway. Even if none of the existing textures support it, it'll be available when you or someone else goes and vamps up the texturing system.

Does anyone know the proper way to add Luxrender's bump and texture functions to a material? I needs the proper syntax cause I'm too stupid to figure it out ;o).

Laurie

One more stupid question, and this one is probably for bagginsbill to answer since he's examined the materials and how Luxrender uses them probably more than the rest of us...

Is it possible in Luxrender to mix a material by either a function, like a noise type, so that something can be made such as a rock material with moss speckled on it? I guess it would need to apply to bump functions as well... Is there also a way to mix materials by altitude with a thickness component, such as a glass and a matte for instance so that it looks like there's a thick coating of clear glass over a something inside, such as a marble? I'm just curious (and probably thinking waaaayyyy too much...lol).

Laurie

To hopefully not further confuse the issue, I just tried using a tile pattern on natively grown hair, vs hair I made in Lightwave (drew some lines, grabbed an .hr2, removed already present lines, added mine - no normals, no UVs, just lines and their vertices - opened the .hr2 in Poser, fiddled with the 'verts per hair' dial to let Poser re-draw the lines, so it can correctly interpolate the population and not crash... it's a convoluted method, but I found that if you just import the hair as an .obj, it will preview, but won't render at all - apparently it loses it's 'W' element?)... and got this. What the heck is this? :tongue2: I'm sure that's saying something about how the hair rendering works, but I don't know what. :blink:

 But as I said, it uses hair shaders just fine, as you can see in the lower image.  Beats me... ;p
 

Quote - But in fact one simply constructs the cross section at the base and then shifts it along the polyline by projecting onto the plane normal to the bisector of the consecutive line vectors at each joint.

...It strikes me, that I have no idea what you just said. LOL. I'll settle for "short of miraculous".

So, I may have to find a new hacked-up hair method, if UV mapping will be required? For now I will be good, and use Poser hair properly. That is, sticking to hair that other people made, since I'm useless with the styling tools. :m_wink:

  Ice-boy - I have to wonder, now, if Silver Surfer ever tried to defeat his opponents simply by standing in the sun and blinding them.  :laugh:  Very nice! 

For "workaround" I have the Dynamic Hair Converter (shareCG) and it works fine.
If someone has interest I can explain how works a dynamic hair conversion.

Quote - Is it possible in Luxrender to mix a material by either a function, like a noise type, so that something can be made such as a rock material with moss speckled on it?

Create a noise texture with the "float" attribute and use this texture name  as the "amount" parameter of the mix.

Lux Renderer is the best thing ever made. good luck with LuxPose

Dynamic hair converter... I never saw that!  Handy... now you need one that converts simple models into dynamic hair.  Would save a lot of copy-pasting.  :biggrin:  

Attached Link: http://www.sharecg.com/v/27296/Software-and-Tools/Dynamic-hair-converter

It can be useful for many cases keeping the polygon count low.