Go to Aux camera for an overview of the scene, there maybe something blocking that you are not picking up with the main camera.

Sidetrack:  where does the code go for the sunsky light?  I missed that somewhere.

you put the light code in the lxl file. I'm trying the same scene with a skydome, before I was using a plane with an image on it. Maybe that was casting the weird shadow.

TY

your welcome :)

 I really wish I knew what I was doing wrong.... I get rid of all of the relative paths in the lxm file and make them constants. I make sure that all the paths are correct to images... I try to run it in LuxRender and it crashes... I live all the relative paths, I get errors in LuxRender but it still runs and renders fine on one machine, even though from what I am told it should have problems rendering correctly. I seem to be the only one having this problem. :unsure:

Quote -  I really wish I knew what I was doing wrong.... I get rid of all of the relative paths in the lxm file and make them constants. I make sure that all the paths are correct to images... I try to run it in LuxRender and it crashes... I live all the relative paths, I get errors in LuxRender but it still runs and renders fine on one machine, even though from what I am told it should have problems rendering correctly. I seem to be the only one having this problem. :unsure:

Mention ALL that in the dev thread and also what version of Poser, your OS and other info that may be handy to the programmers.

Laurie

But you have errors caused my material problems. I often see Lux crash when it reports problems, especially if I try to start a render over again.

Get rid of the material problems. In Lux, a missing "Texture" is not an image. All the Lux "nodes" are called "Texture".

Note: I've found and fixed the Color_Round bug. It's actually caused by a Math:Color_Sub (subtract) node being decoded incorrectly.

But I can tell you that even with my correction, subtraction doesn't work. There is no subtract "texture" in Lux. I thought I had a solution using "mix" but it turns out that Lux refuses to mix negative colors. It just does not tolerate the idea of values outside the range of 0 to 1, even if they are brought back into range later. So it is pretty much impossible to do math, other than multiply, in Lux shaders. And even then, the values are often clamped to the unit range.

The designers of Lux don't really grasp how procedural shaders are done. The only way I'm going to be able to implement the kinds of procedurals we use in Poser is to change the C++ code, which I plan to do.

It has some nice pattern generating functions, but you can't combine them in all the ways that are needed.

For example, yesterday I tried to use the Dystopia city set. In there is a procedural for slightly rusty galvanized metal. The look of galvanization was accomplished by taking a clouds node, multiplying it by a large number, rounding that off to an integer, then dividing by the original large number. The result is that you get chunks of solid gray in various shades, instead of a cloudy pattern. This is a very common technique, and impossible to do in Lux procedurally.

Rendered 2:42 (Stats on the bottom)
Question, If I Save it as and "FLM" while it is still running, can i load and resume rendering?
I stopped the render and saved as FLM, that doesn't let you resume rendering.

I'm still learning and not totally happy yet.

Kernal: Linear

Yes.  Go back and choose 'Load FLM.  It will ask first for the scene file, then for the flm file.  It will then continue where you left off.

It's important to note that it asks for the scene file, so make sure you keep the .lxs file for the scene you want to resume later.

Question for BB: from what I've read earlier, you were planning to add more texture types to LuxRender in order to have a complete node-based shading system a la Poser. But if you create your textures procedurally, anyway, is it really a good idea to do it via a whole bunch of separate texture objects?

Wouldn't it be more useful to instead just add one new texture type "procedural", which would define its own shading language a la matmatic? Internally, it may make sense to represent elements of the shading scripts as nodes, so you can do all kinds of optimizations on the generated shader. You might even get ambitious and provide a graphical interface for creating node-based shaders as in Python. But I see no strong reason why all of these nodes would have to be proper LuxRender "textures". If you use your own internal node type, you can happily deal with negative and very large values, and you just clip them to the range that Lux is comfortable with at the very end.

Just a thought.

Yes, indeed, that would be a good approach. In fact I had thought to do the same for Poser, with SM, of course.

Quote - Snarlygribbly: I tried your camera settings in Poser Pro 2010 (inches as units and everything), but couldn't reproduce your problem at all. I tried versions 12 and 14b, since I'd just deleted 13a.

Very mysterious!

Just to mention it: You can download previous versions (from 1-11 up) if you giv the full packagename. To download version 1-11:

http://www.poserprofis.de/PoserLuxExporter_Alpha/PoserLuxExporter_alpha_1-11.zip

I know, it's a bit typing. But better than nothing ;)

Quote - I agree that it would be useful to get to the bottom of this. I have to catch some sleep, but I'll look at your test scene tomorrow.

Since the field-of-view correction for viewports that are wider than high hasn't yet been incorporated into ADP's package, it would probably be best to only use square or portrait formats for these tests for now.

I got lost by this discussion. I got only emails for the main PoseLux thread.

Now I know what dizzi talked about :)

Fixed and working in the new Version 1-15c

Quote - Yes, indeed, that would be a good approach. In fact I had thought to do the same for Poser, with SM, of course.

I wouldn't be surprised if the LuxRender developers get in touch with you at some point so you can do the coding for that.

BB just a little food for thought, would it be terribly difficult to add LuxRender as a permanent integrated part of future Poser releases?

I know we have the Poser4 & Firefly renderers already but having something like LuxRender called directly from Poser itself without mucking about with python scripts & exports would be something just a little bit special wouldn't it?

problem is, you are then moving into licensing territory..... lawyers get involved... hassle and trouble ensue.. money! money gets involved.....

Lucifer and Kai,

Kai brings up a point that I'm certainly unqualified to confirm or deny.

I believe it is OK to package and distribute LuxRender with Poser, just as it is OK to package and distribute Python with Poser. It is open source. Reality also packages and distributes LuxRender and I'm pretty sure Paolo did not ask permission first. I think that because just a couple days ago he was speaking to the main Lux dev in the Daz forum, and it was obvious it was the first time they had ever communicated.

The downside is that if SM were to include it, they would be taking on support issues.

Customer: Smith Micro you stupid morons, why do I get these white dots when I render in LuxRender?

SM: Please speak to the LuxRender developers. We just included it. We didn't write it.

Customer: Why did you include broken software? Why do you make Poser so dependant on 3rd party software? Why why why don't you hire 1000 developers but still sell me Poser for $30?

SM: * Sigh *

In any case, I doubt LuxRender would be added before it at least got to a full point release. Can't see a commercial product including something that is at 0.xx.

I suspect they'd also worry about things getting broken in relationship to Poser as LuxRender further develops. It's a commitment that could be a headache for them.

they can have a big banner on the SM site for Luxrender. then the links points to the LuxPose site.

No, bagginsbill and others are right. SM can't include Luxrender because of support issues. I agree. We're better off just doing what's already being done with the LuxPose plugin. Just look at all the "support" questions for it so far when it was made perfectly clear where the whole thing was in the process. It would be a nightmare.

Re-edit: also, why would SM want to support a third party plugin? It's not their responsibility that no one will barely even know how to use Luxrender, let alone have to answer a barrage of complaints about it. It's not a point and click solution. It's going to take come learning (and unlearning IMVHO) to get anything really good out of it.

Laurie

Well, SM have plugins for the 'big guns', maybe they could package up a proper LuxPose exporter as well :)

They could do that, but they would probably only include that with the Pro version.

the simple  path is to make it the addon of choice simply by learning it, using it, and teaching others how to use it and where to get it.

Quote - No, bagginsbill and others are right. SM can't include Luxrender because of support issues. I agree. We're better off just doing what's already being done with the LuxPose plugin. Just look at all the "support" questions for it so far when it was made perfectly clear where the whole thing was in the process. It would be a nightmare.

Re-edit: also, why would SM want to support a third party plugin? It's not their responsibility that no one will barely even know how to use Luxrender, let alone have to answer a barrage of complaints about it. It's not a point and click solution. It's going to take come learning (and unlearning IMVHO) to get anything really good out of it.

Laurie

they can promote realistic renders. more people will buy Poser to render realistic human figures and for posing they need Poser.

it will be good for SM and Poser.

Quote - > Quote - No, bagginsbill and others are right. SM can't include Luxrender because of support issues. I agree. We're better off just doing what's already being done with the LuxPose plugin. Just look at all the "support" questions for it so far when it was made perfectly clear where the whole thing was in the process. It would be a nightmare.

Re-edit: also, why would SM want to support a third party plugin? It's not their responsibility that no one will barely even know how to use Luxrender, let alone have to answer a barrage of complaints about it. It's not a point and click solution. It's going to take come learning (and unlearning IMVHO) to get anything really good out of it.

Laurie

they can promote realistic renders. more people will buy Poser to render realistic human figures and for posing they need Poser.

it will be good for SM and Poser.

Except for the fact that those realistic renders will take real work and a lot of folks just don't want to work that hard at it ;). It's been rather misleading for them.

Laurie

Quote - > Quote - > Quote - No, bagginsbill and others are right. SM can't include Luxrender because of support issues. I agree. We're better off just doing what's already being done with the LuxPose plugin. Just look at all the "support" questions for it so far when it was made perfectly clear where the whole thing was in the process. It would be a nightmare.

Re-edit: also, why would SM want to support a third party plugin? It's not their responsibility that no one will barely even know how to use Luxrender, let alone have to answer a barrage of complaints about it. It's not a point and click solution. It's going to take come learning (and unlearning IMVHO) to get anything really good out of it.

Laurie

they can promote realistic renders. more people will buy Poser to render realistic human figures and for posing they need Poser.

it will be good for SM and Poser.

Except for the fact that those realistic renders will take real work and a lot of folks just don't want to work that hard at it ;). It's been rather misleading for them.

Laurie

Laurie you are thinking way to much about dumb people. yes i wrotte dumb. this was not a mistake.

if they can read and if they make a mistake its their own fault.

I just heard about luxrender through the recent hoopla over the daz product and I'm absolutely delighted that folks are working on an exporter for poser! many thanks to everyone who is involved in the development of luxpose! :)

Quote - > Quote - > Quote - > Quote - No, bagginsbill and others are right. SM can't include Luxrender because of support issues. I agree. We're better off just doing what's already being done with the LuxPose plugin. Just look at all the "support" questions for it so far when it was made perfectly clear where the whole thing was in the process. It would be a nightmare.

Re-edit: also, why would SM want to support a third party plugin? It's not their responsibility that no one will barely even know how to use Luxrender, let alone have to answer a barrage of complaints about it. It's not a point and click solution. It's going to take come learning (and unlearning IMVHO) to get anything really good out of it.

Laurie

they can promote realistic renders. more people will buy Poser to render realistic human figures and for posing they need Poser.

it will be good for SM and Poser.

Except for the fact that those realistic renders will take real work and a lot of folks just don't want to work that hard at it ;). It's been rather misleading for them.

Laurie

Laurie you are thinking way to much about dumb people. yes i wrotte dumb. this was not a mistake.

if they can read and if they make a mistake its their own fault.

Yes, it is their fault in that case.  That won't stop them from asking for support from SM, and then SM will have a hard decision to make.  Either they go ahead and commit resources to support Luxrender, or they don't and have a PR fiasco as they lose future business.

Well it was worth asking the question even if the answer has to be no.

Too many individuals expect the convenience of plug n' play rather than take the time to learn the proper procedure.  We are too impatient, period.  Ask yourself, "how many times do I bother to read the instructions before assembling?"

There's instructions?

Yeah, right after the disclaimers.

Quote - Too many individuals expect the convenience of plug n' play rather than take the time to learn the proper procedure.  We are too impatient, period.  Ask yourself, "how many times do I bother to read the instructions before assembling?"

Aren't instructions those things "other" people read? I usually throw them away & just dive right in. ;)

But something tells me I'm going to have to start reading them instead.

Quote - There's instructions?

Really. I thought I got everything thru osmosis...lol.

;o)

Laurie

That only works if you place the manual under the pillow while you sleep.  This might work well if you own an IPAD.

Quote - That only works if you place the manual under the pillow while you sleep.  This might work well if you own an IPAD.

Maybe I should try subliminally then ;o)

Laurie

so my manual I'm writing would be useful...

Rendering In Luxrender.
A beginners guide

"Want to use Luxrender? well listen up Nugget. You've got things to learn and unlearn.
First is, everything casts shadows. everything. this is physics at work. and it's a harsh mistress.....

tho... I think I may need to work on the wording...

How big of a shadow does the sun cast?

Couldn't resist.  Sorry.

I thought that was the dedication page!?  ;o)

Laurie

Quote - How big of a shadow does the sun cast?

Couldn't resist.  Sorry.

actually.. if there was a bigger stronger light source it would have ;) weak, but there would be one ;)

Poser needs "only" a smooth working interface to LuxRender. The main part of that is common for all external renders: Getting out the renderman based material node system to something other render engines can use. Sort of intermediate material description. 

Any 3DApplication with an interface to EPM (External Procedural Material) as mentioned by odf and BB, has an automatic option to extend their userbase by some ten thousend Poser users (and probably DS users, too) for each of the few 3D flagships.

LuxRender, as a free and Open Source render engine with a direct API, is the right one to show how it can work. At the end, inserting EPM into the own 3D-software is anything needed. A softtware company just has to have a (paid) license to do so and can request support to implement the cash-cow-interface.  Means: some money and probably a week of manpower for a new, extened software release.

Getting a Patent for EPM isn't  easy anymore. Because it is decribed here, it is "prior art". But I'm sure at least for the US it's possible to get one or more blocking patents (the "neuronal part" how to convert a bunch of nodes to one expressive material, for example).

For SM this means a breaktrough into professional 3D-market. Accompanied from their marketing engine SM are "the good people" without any cost for marketing/advertising.  Other will spread the word (and pay for advertising). For the investors it means: ROI by license selling and an extended market. Not only for Poser alone. SM's online-market will be extended by a lot of professional marketeers, advanced products and highly motivated costumers waving with their CC-cards.

So, all together an extreme "Win-Win" situation. What is it SM is waiting for?

Quote - No, bagginsbill and others are right. SM can't include Luxrender because of support issues. I agree. We're better off just doing what's already being done with the LuxPose plugin. Just look at all the "support" questions for it so far when it was made perfectly clear where the whole thing was in the process. It would be a nightmare.

Until it's ready for the market, a support infrastructure is already implemented by the userbase. Just the same as with any other important 3D-App.

A decentral (and international) organized costumer Hotline (kind of external Call-Center) initiated by SM can be self-financing. A new customer gets some free "Question Tickets" and can pay for more via SM's market-place. Hotline-Agents have to make an onine-test (costs money) and then they can make a living with what they already do for free now: Telling users about how-to, hot tips and tricks and what ever. But now using Skype or something, not a forum :)

errrrmr ADP?

we have users complaining right now about extended downloads.

can you imagine the howls at your idea................?

ye gods man... the horror!

No problem, Kaibach. 
To loose 10 from thousend is sad, but not a drama. On the other side: This lost people may grow over time and become customers at a later point (absolute normal inside a business; think on professional/semiprofessional Photo-Equipment - some users aren't able to unfold a professional tripod :) ).

subdivision 3?

dear lord this is way to much.

then else is wrong.