Quote - This is what the globe looked like without subdivision, tell me again it's too much. :)

Can you do another try with: normalsprops=false, please? (in file AIR/data/dataOut.bbml) 

Quote - > Quote - This is what the globe looked like without subdivision, tell me again it's too much. :)

Can you do another try with: normalsprops=false, please? (in file AIR/data/dataOut.bbml) 

yes, the first one, while cool looking, looked like weird vertex normals ;o). (/ )

Laurie

Laurie,
you are on the way to become a specialist !

Can you please post your Lux skin-material again? I want to make a shortcut to replace a complete skin on demand using the image found in Posers node setup. Without changing anything in Posers materials, of corse.  Perhaps by a GUI entry.

Like I said, I'm not sure the translucency converted over. I can't tell ;o). The thing is though, that skin settings isn't going to look good in all light or all tone-mapping choices. Sorry I stated the 'obvious' again ;o).

The translucence color is R110, G45, B42

Laurie

For the snow globe, it's probably best to let Lux do the subdivision. I've implemented Catmull-Clark in the exporter because Lux gets its meshes cut apart at texture seams, which leads to visible seams when Loop subdivision is used inside Lux. Since you have no texture on the glass, you don't need it UV-mapped, and with no UV-mapping, there will be no texture seams.

If you can find the 'Shape' instruction responsible for the snow globe in your output .lxo file, simply insert a line like the following right after it:

     "integer nsubdivlevels"
[3]<br></br>

Then you could try to crank that level up until the glass looks smooth enough.

You might also want this line, but I'm not exactly sure what it does (so maybe not):

     "bool dmnormalsmooth"
["true"]

An alternative would be to use a sphere shape or nurbs, but obviously that's not supported by the exporter, since Poser doesn't have those.

Quote - then else is wrong.

I think it's probably the fact that Lux is more precise than conventional renderers when computing refraction. In Poser, everything's pretty fuzzy, so it won't really matter that much - or so I suppose - whether you have a perfectly smooth curved surface or an approximation by tiny polygons. In Lux, it does.

As I said, the alternative would be to use a mathematically smooth surface, which Lux apparently supports, but Poser and LuxPose don't.

Quote - For the snow globe, it's probably best to let Lux do the subdivision. I've implemented Catmull-Clark in the exporter because Lux gets its meshes cut apart at texture seams, which leads to visible seams when Loop subdivision is used inside Lux. Since you have no texture on the glass, you don't need it UV-mapped, and with no UV-mapping, there will be no texture seams.

If you can find the 'Shape' instruction responsible for the snow globe in your output .lxo file, simply insert a line like the following right after it:

     "integer nsubdivlevels"
[3]<br></br>

Then you could try to crank that level up until the glass looks smooth enough.

If you look back a few posts you'll see another render of the snow globe with a subdivision level of 3, it's a lot smoother.
Thanks for that option. :)

Quote -
If you look back a few posts you'll see another render of the snow globe with a subdivision level of 3, it's a lot smoother.

Yes, I saw that. I'm just saying that if you need a really high subdivision level, it's probably better to do the subdivision in Lux rather than in the exporter. I've added that as an option to pydough the other day, so maybe ADP can add it to the interface.

Cool, that might be handy to single out a single object. Thanks.

Quote - > Quote -

If you look back a few posts you'll see another render of the snow globe with a subdivision level of 3, it's a lot smoother.

Yes, I saw that. I'm just saying that if you need a really high subdivision level, it's probably better to do the subdivision in Lux rather than in the exporter. I've added that as an option to pydough the other day, so maybe ADP can add it to the interface.

odf,

Seems that your code allways computes normales, because the GUI-value is a string ("true" or "false").  If you change line 23 to:
if options.get('compute_normals', "true").strip()=="true":
the result should be exact.

As for the Lux-subdivision: I'll add a GUI-parameter named "lux_subdivision" with a value.

Quote -
Seems that your code allways computes normales, because the GUI-value is a string ("true" or "false").  If you change line 23 to:
if options.get('compute_normals', "true").strip()=="true":
the result should be exact.

First of all: I'd already fixed that in my code several days ago and said so in the main thread. You ignored it, as you usually do, and used some older version.

Second of all: it's up to you anyway to call worker code with correctly typed values.

Here's the deal: I do no longer care what you or BB do in your frameworks. I will write my code the way I think it should work, and you can take it or leave it. I will add my own little GUI at some point, so I won't have to pull my hair anymore at your assorted mess. Sorry if that's a bit harsh, but I don't have the time, energy or ambition to babysit either of you.

Quote - > Quote -

Seems that your code allways computes normales, because the GUI-value is a string ("true" or "false").  If you change line 23 to:
if options.get('compute_normals', "true").strip()=="true":
the result should be exact.

First of all: I'd already fixed that in my code several days ago and said so in the main thread. You ignored it, as you usually do, and used some older version.

Second of all: it's up to you anyway to call worker code with correctly typed values.

Here's the deal: I do no longer care what you or BB do in your frameworks. I will write my code the way I think it should work, and you can take it or leave it. I will add my own little GUI at some point, so I won't have to pull my hair anymore at your assorted mess. Sorry if that's a bit harsh, but I don't have the time, energy or ambition to babysit either of you.

Would you please take in account that we hear since at least 14 days: Wait, hold, my GUI does it all - just not yet but I'll be up early tomorrow morning to make this ready. After the next "soon as by DAZ" announcement the thread gets splitted up into at least 3 and anybody posted everywhere fixes and what else.

I don't know anymore what to do and what not.  I can't sit the whole day and look if anybody did something. If you are online, it's very early in the morning here. But some times I have to sleep and work.

We should make a decision: Dropping this or reorganize. At the moment I just see chaos and a lot of dreams and frust.

False alarm - I had the older code in my "sandbox copy". The zip (and the working copy)  has  your actual code.

What I have to add is the GUI parameter. Sorry for the confusion :)

GUI parameter for Lux subdivision added. 

Quote -
We should make a decision: Dropping this or reorganize. At the moment I just see chaos and a lot of dreams and frust.

The thing is, I still have quite a bit of work on the geometry exporter lined up, which is why I kept out of the whole framework/interface business for now. On top of that, I've been neglecting Antonia for too long, and what I really should be doing at this point is work on some kind of portfolio, so that eventually I'll have a chance to find a more interesting job or go freelance.

Here's a suggestion: if we don't see BB's super-fantastic, fully integrated LuxPose within the next month, I'll be available to talk about how to reorganize the project. I think we have quite different views on some things, and I'm not sure we can always find an agreement (in fact, I'm afraid I'm more likely to agree with BB on most things). But at least we can discuss things and try to make a fresh start.

Quote - I think we have quite different views on some things, and I'm not sure we can always find an agreement (in fact, I'm afraid I'm more likely to agree with BB on most things). But at least we can discuss things and try to make a fresh start.

I have no problem to change direction. At this point whats needed is pretty clear. So how to do it best is just a matter of an agreement.

About BB: There are so many things he is involved to the same time, doing big steps forward is pobably not easy for him. To make a real smart material converter, he needs to extend the Lux code. No way around this. This costs time. Not only for the coding part.

By the way: Did you see the converter for Google SketchUp? It's written in Ruby and uses a (simple) Http interface.

Just to be clear: I'm not blaming BB for needing time to get things ready. I'm not even blaming him for playing it close to his chest. That's his way, and his results tend to be spectacular, so I'm all in favour of him doing things the way that he prefers.

I also realize that you're in a tricky situation, since you want to give people something to play with while at the same time avoiding to waste your time with code that will be made obsolete later. It's easier for me since I'm working on one little corner of the project that's relatively simple to keep separated from the rest and that I can have all to myself.

Writing GUIs with HTTP, CSS and Javascript is a large part of my daily work, and I find it a much more pleasant approach than the traditional way. Maybe I'll have a go at that at some point.

Quote - Just to be clear: I'm not blaming BB for needing time to get things ready. I'm not even blaming him for playing it close to his chest. That's his way, and his results tend to be spectacular, so I'm all in favour of him doing things the way that he prefers.

I also realize that you're in a tricky situation, since you want to give people something to play with while at the same time avoiding to waste your time with code that will be made obsolete later. It's easier for me since I'm working on one little corner of the project that's relatively simple to keep separated from the rest and that I can have all to myself.

Writing GUIs with HTTP, CSS and Javascript is a large part of my daily work, and I find it a much more pleasant approach than the traditional way. Maybe I'll have a go at that at some point.

So we are almost close.
I really hope BB can make an outstanding interface to open Poser users a new world while keeping the benefits from the material room. If someone is able to do this, than it is BB. No question. 

But, as you mentioned, to hold the project "hot" we have to go some steps forward. A three-teer approach could keep things going. An App-Server written in Python 2.6/3.0 in between Lux and Poser. Something like this is required anyway, because Lux's Python interface supports 2.6/3.0 only. But Poser sticks with Python 2.4 and so isn't able to use the Lux-API. On the other side, Poser is able to call the App-Server if anything changes (light, camera, etc) to update Lux in realtime.

Writing such a stand-alone App-Server is trivial. It's not mutch more than extending existing libraries.

Using Javascript and probably  HTML5 features can come out with a really nice user-interface. But this is something you know better :)

BB has more time if he can concentrate on material convertion and extending Lux with some material features. If he is ready, using the three-teer structure or do it his own way at the end is up to him. I see the material-convertion (and material handling/creation) on Posers side as a kind of stand-alone App. Able to connect to Poser, to Lux, or even to an App-Server.

An interesting thread on the Lux Site about features for version 0.8

pciccone wrote:- Improvement to UV mapping. The way Lux requires the UV creates a lot of problems for subdivision. Because the UVs require the repetition of the vertices at the edges, when exporting to Lux the objects are actually unwelded at the uv seams. This causes some visible lines in certain times but it completely prevents the use of subdivision on those object since the seams will become completely visible. If there would be a way of weld the seams it would be great.

             Already in Mantis: http://www.luxrender.net/mantis/view.php?id=820

For the whole thread see: http://www.luxrender.net/forum/viewtopic.php?f=27&t=4487 

Maybe this should go into the other thread?

Anyway, I'm not interested in anyone's grand vision, and maybe that's the problem. I like to build small, simple components that work. Then once I have enough of those, maybe I can combine them into something bigger.

Maybe I'll build an HTTP interface. It would be useful practice. But maybe I'll just quickly whip one up in Tkinter for now, so that I have something to test my code with and that I have control of.

If you're interested in that application server, by all means build it. It sounds very useful, if not for this project, then maybe for a future one. The trick, I think, is to stay out of each other's way as much as possible and work independently on things we know will be useful.

Edit: Crosspost! The thread about changing the UVs sounds interesting. I need to create a login before I can read it, but I will. I really, really hope they'll address that problem soon.

adp: if it were me helping to program all this, I would ignore every thread other than the LuxPose development thread, at least for code snippets. Most of the programmers know to post their code donations there ;o). If they post it in here and I catch it, I'll remind them to post it in the dev thread so that you can spot it.

This is exactly the reason I thought a private forum for the programmers would be a good idea: too much idle chatter from others and some things get missed/lost :o(. BB didn't want to do it that way, but there's a difference between keeping things coherent enough to get any code changes implemented and wanting the members to see the whole thing coming together. I don't see why there should be a problem between the two.

I'm afraid I've contributed to the problem guys and I apologize for that. I didn't want to help cause any dissension in the ranks ;o).

Laurie

Quote -
I'm afraid I've contributed to the problem guys and I apologize for that. I didn't want to help cause any dissension in the ranks ;o).

No Laurie. We just missed to make cleare where to post :)

Maybe we can make another plea to the other programmers to come over to the private forum, at least to post their code snippets. Be much easier for you to follow. Then you can announce any new builds here and say "New build! We fixed x and y and added z" ;o).

I'd like to see both BB and Dizzi come over to the private forum at least to post code :o).

Laurie

right.
you net Dizzi.

I'll dart BB and get him in the straitjacket.....

The development phase is getting convoluted with the different threads that has cropped up.  I have been following closely, but have found that some of the render experiments have lacked structural, information clarity for someone else to pursue or duplicate.  It would be great if a step-by-step mini instruction could be included with specific renders, so we could understand the development better and see where these changes need to be implemented to achieve the fiinal end results.

I would propose 4 threads:

The development
The Wishlist
Questions
Renders and How To's

erm
Hborre? thats exactly what we have now...!

And the programmers are getting lost in them I'm afraid :o(.

Dizzi posts something....it gets missed. odf posts something, it gets missed. It's even getting hard for me to follow and I'm not even a programmer ;o).

Also, I added Dizzi to the active programmers on the wiki page since he/she has contributed quite a bit thus far. I hope Dizzi comes back :o(.

Laurie

Quote -
Also, I added Dizzi to the active programmers on the wiki page since he/she has contributed quite a bit thus far. I hope Dizzi comes back :o(.

I really wish that too!

Kaibach, the structure of these threads are too flexible.  You post in one, you need to post in another.  May be the best alternative is to sticky all Luxrender threads, and to adhere strictly what content is posted where.  It should make it easier to find specific information if guidelines are implemented.  I need the latest development news, go to the development thread; I want to see what others are doing with Luxrender and learn how they do it, go to the render thread.

thats what the plan was....... but it got screwed up when ppl just posted whereever.

Quote - Kaibach, the structure of these threads are too flexible.  You post in one, you need to post in another.  May be the best alternative is to sticky all Luxrender threads, and to adhere strictly what content is posted where.  It should make it easier to find specific information if guidelines are implemented.  I need the latest development news, go to the development thread; I want to see what others are doing with Luxrender and learn how they do it, go to the render thread.

I've tried to keep the threads on topic, but chatter happens I'm afraid. I can't control open threads from my little corner of the world ;o).

Laurie

That would nice if it worked as it was intended.  However, no one here has the power to move threads, or otherwise force compliance.  Laurie is doing the best that can be done to nudge people that way.  Since this is not a sponsored project, we don't get special priviledges; at least not much.  Getting the first post stickied is about all we can expect.

Besides, the world can't exist without some chaos!

Laurie has put in a lot of effort into organizing this endeavor, and she is right, can't control the content and nature of the posts.  There is a handful of testers already, with others silently waiting in the wings for something major to happen.  Numbers are small enough to handle.  Just generate some guidelines that can be simply implemented and followed.  Make easier for someone to track down information in one place rather than search in four.

ok. question.

we asked ppl to use the threads. they did'nt.

so what now?
make another set of threads ? and then ask them again?

I guess that would be counterproductive, wouldn't it? 

Maybe if we should sneak into the homes of the non-compliants, and beat their feet with a baseball bat. :)  Hey, I like that idea!

Quote - I guess that would be counterproductive, wouldn't it? 

Maybe if we should sneak into the homes of the non-compliants, and beat their feet with a baseball bat. :)  Hey, I like that idea!

OMG...can we? That would almost be too much fun ;o) However, I prefer the more primitive approach. A board with nails....

Laurie

oh now your talking!!!

can I bring my 2x4?

Better yet, force them to listen to 24 hours of Justin Bieber.

Nails & bats!!  This will be a gore-fest.

Quote - Better yet, force them to listen to 24 hours of Justin Bieber.

Now THAT'S just sadistic.

;o)

Okie doke....back on track...lol.

Laurie

Suspend them upside down in a vat of boiling yak turd, and then feed any remains into an Insect Horror Machine programmed by Death Demons.

For those that would like to test some IBL in their renders, lots of nice free .hdr files here and hi-res too :o).

http://www.hdrlabs.com/sibl/archive.html

Laurie

TY, Laurie.  Looks like an interesting site.

not to go off topic.....what a shame Poser dosen't have a python script to allow their (hdrlabs.com) sIBL/fgui setup to work within Poser. Load the IBL light, pop in the corresponding sunlight and specular light with accurate positions and the provided environmental map into BB's environ-sphere.  Ive been doing it for a while but manually, lol. That would be amazing!!!!

LuxRender question - anyone here familiar with the development cycles over there?  I'm curious about how long they take to update.  I am interested in future GPU rendering capabilities... is there an eta? How about a stab in the dark? lol

certainly.. stand there and I'll get a knife and turn the lights out..

but seriously.. seems pretty rapid.. they're working hard on .8... and the GPU side is slated for .8.. they've been turning out code on that side rapidly...

Apparently there's a version 0.7.1 just around the corner, which presumably will fix some of the most annoying bugs in 0.7. I think the GPU version is already available as a separate download (don't quote me on that, though :laugh:), but obviously it's still very experimental.

ok, cool, thanks :)

cheers on LuxPose devs 8)

Looking at historical releases it looks like there was approx. 6 months between 0.6 and 0.7, I'd expect 0.8 to drop in the 1st few months of 2011.

There is a development version of SmallLuxGPU (SLG), which you can find in the source repository and in the weekly build forums but, from reading the forums, I got the idea it's currently only accepting input from a special version of the LuxBlend exporter.

If anybody knows better I'd be happy to be corrected. :)