Attached Link: http://www.renderosity.com/mod/gallery/index.php?image_id=2106024

can somebody do a render of a multifaceted diamond on a diffuse/specular surface using
sunlite or spotlite?  I tried it in maxwell render but it came out all grainy (didn't know how to use it).

Quote - can somebody do a render of a multifaceted diamond on a diffuse/specular surface using
sunlite or spotlite?  I tried it in maxwell render but it came out all grainy (didn't know how to use it).

Try to put your diamond in a tight box or sphere. Make sure there is not too mutch light-bouncing in your environment (walls/ceiling without reflections). Give the rays a chance to find your diamond :)

How long did you let it render??
and what was your lighting set up??
We have Maxwell 1.7 and like LUX it takes a "while" for the graininess to clear up.

Cheers

"If I use the sunsky from above, my log says:

[2010-09-08 05:08:42 Warning: 0] Parameter 'aconst' not used

[2010-09-08 05:08:42 Warning: 0] Parameter 'bconst' not used

[2010-09-08 05:08:42 Warning: 0] Parameter 'cconst' not used

[2010-09-08 05:08:42 Warning: 0] Parameter 'dconst' not used

[2010-09-08 05:08:42 Warning: 0] Parameter 'econst' not used

[2010-09-08 05:08:42 Warning: 0] Parameter 'L' not used

[2010-09-08 05:08:42 Warning: 0] Parameter 'L' not used   "

i get these messages too, & after experimenting only 'aconst' seems to do anything when changed (1 is bright; 0 is dark)  tried changing to 'sun' as suggested but then i get nada.   maybe our coding is wrong?
 

tap...tap, testing...

Paging bagginsbill?

tap, tap....is this thing on?

;o)

Laurie

I'm reading but don't have time to participate. As I said recently, things are going to get nutty for me in September.

It's ok...lol. Just wanted to make sure you were breathin' ;o).

Laurie

I cannot seem to get the line coding correct, an example would be a great help :)

also, wondering about the faceting issues, maybe I am unclear as to what needs to actually be done here...

In the attached image I am using a Glass mat on the Poser primitive Ball (Large) on the right is the HiRes Ball primitive, both of them show the mesh, is this correct for as far as exporter goes for the time being?

Quote - I'm reading but don't have time to participate. As I said recently, things are going to get nutty for me in September.

BULLSHIT

http://www.runtimedna.com/forum/showthread.php?55091-All-the-attachments-are-back&p=539044#post539044

"I am enjoying the iPad so much that I refuse to get my laptop or desktop out again. As a consequence, the folks at rendo have been without my advice on shader matters for two days now, because I cannot use the forum reply from iPad.

Sucks for them. They want a whiskey material and also discussion of luxrender. Hehehe. Love my iPad."

kaibach i think it would be better if you would add a smile. now it looks like you are angry and serious.

;)

I'm not smiling. I'm actually furious.

I'm done and going away for awhile.

but we can not be angry because he took a brake. he is doing all of this for free for years now.

now he is working on complex coding to make the transition from Poser to Lux as simple as possible.

Patience?  Please?   :blink:

That quote is from a few days ago. Yes, over the Labor day weekend, when my daughter was visiting before going off to college, I took a break from work and from Poser and we were all playing with the iPad and enjoying each other's company.

I'm completely burned out due to weeks of lack of sleep. Now it's Wednesday and I have another product demo to due tomorrow and I don't have time at the moment to play with Poser.

I've done a ton of stuff with the exporter, but seeing how things got a little wonky what with people expecting it to do more than it was capable of, I feel really uncomfortable publishing anything half-assed.

There is a desire to use IBL. adp did some work there, but it requires more complex handling that I don't have time to fix.

We want the app server included, and I have it running, but structurally it is a little bit ugly and I have some small amount of refining to do. As well, I have to integrate adp's sub-classing of the Poser object so that it can run safely in the background all day even if you run other Python scripts that steal the scene event callback. The way it is right now, if you're running on Poser 8 or Pro 2010, it uses a wxTimer - that's new in the past couple weeks. But if you're on Poser 7 or 6, it has to use the scene event callback and it will, but if you run some other script it will mysteriously stop. I do not want to debug that with people. So it will wait until I have time to make it foolproof.

The spotlight export falloff isn't right and never was. I have to figure that out before I publish another set of light exporters.

The ambient power issue we ran into still needs investigation. I saw the post saying that setting "power" or "efficiency" to 0 will disable the power scaling with size, but when I tried it, it didn't work.

There were issues with the AIR installer, and I have it working without installing (I think) for Windows, but not for Mac. I have a Mac to try things with but it is terribly slow and I spent hours with it not getting the info I wanted. It will take me at least another 10 hours to figure out how to deal with a not-installed AIR GUI on the Mac.

I also have to make that work in Linux. Don't know how.

The light group prefix hack seems not a winner, so I have to put the per-light GUI in and let you set the light groups in LuxPose so you won't have to change your scene light names.

Overriding the per-material settings is necessary and I have to build the GUI, the server callbacks, and the business logic to deal with that as well.

I don't want any more confusion about black renders, so I feel I need to assemble a few reference scenes so that there is no confusion by new users as to what is happening or not happening.

The light gain factors are not consistent across different integrators and I know that adjustment is needed but I haven't figured out exactly what that adjustment is.

I proposed using the Sun+Sky option, which I implemented (which required that I rotate the world). But since then the geometry exporter has been updated so I'll need to go into it an re-apply the changes to odf's newer code so as to again rotate the world. There was also the request to separate sun and sky as independant options. Since that changes the data model, and since I'm trying to publish an exporter that supports presets, I have to decide the final data model first. Otherwise, all the sun and sky presets will be useless. 

There are other similar niggling issues.

In other words, I've already put another 90 hours or so into LuxPose since my last publication of anything, but since I see how it gets used, I'm not going to publish any of this until the rest of the changes I described above are finished. That could take another 40 to 100 hours. I don't have that much time.

I do have enough time to answer Syyd because I owed her one. (There were other conversations in PM that you're not aware of, nor should you be.)

Please, continue to have a life.  I for one have enough stuff here to keep me busy for awhile, LOL. 

Well since it's such an issue that Kai is angry, let me post this.

It is not ready for users, in my opinion. I'm posting it so other developers (adp, odf, dizzi, etc.) can have a look and get familiar with how things work now.

https://sites.google.com/site/bagginsbill/free-stuff/luxrender-exporter

Make sure you're using the newest Lux version (0.8dev) for material testing and lighting because lots of things will work differently than in 0.7

This is the metal line used in this picture:
MakeNamedMaterial "Victoria4/metalorb" "string type" ["metal"]

"string name" ["aluminium"]

For Mirror it would be like:
MakeNamedMaterial "Victoria4/metalorb" "string type" ["mirror"]

"color Kr" [1.0 1.0 1.0]

I didn't bother with the film and filmindex parameters.

In this picture I also tried to use the mattetranslucent material on the skin, sample line:
MakeNamedMaterial "Victoria4/1_SkinFace" "string type" ["mattetranslucent"]

"texture Kr" ["Color_Mul_109"]

"color Kt" [0.08499821195233 0.00499821195233 0.0049]

The Kr parameter seems to control the base skin layer, the Kt parameter controls the colour shining through (use subtle values).
 

Quote - the matter of turning on Java in Safari escaped you I see.

Yes indeed. It continues to escape me even after looking for it again. Assume I'm a total moron.

Instead of being nasty, perhaps you could tell me where this option is?

I still can't Rendo-post with iPad even though the Rendo response box looks just like the RDNA one.

odf,

I was working with pydough and I found a couple problems. I don't remember if I successfully fixed them or how.

Problem 1: A prop hair parented to a figure was being exportered as part of a figure, as well as being exported as an independent prop. A parented hair answers to "ItsFigure" even though it isn't actually one of the figure's actors. This caused a bunch of missing texture warnings, because the copy exported as part of the figure was using the mat key for the figure, not the hair prop. I think I fixed it by filtering on "not IsProp()". But if that's what I did, it's a hack. Instead of iterating over all figures, it should just ask the figure for its actors. It think.

Problem 2: At some point, I was getting materials for two separate figures merged into one set of materials. I sort of remember this being the result of directly calling the exporter for actors even for figures. I can't really recall. Anyway, I think I changed to calling pydough to export a whole figure and that fixed it.  I think.

It's all fuzzy.

Quote - At RDNA, Kaibach said:

Quote - the matter of turning on Java in Safari escaped you I see.

Yes indeed. It continues to escape me even after looking for it again. Assume I'm a total moron.

Instead of being nasty, perhaps you could tell me where this option is?

I still can't Rendo-post with iPad even though the Rendo response box looks just like the RDNA one.

What would you need Java?
I can post (apparently), yet Java is totally disabled on my browser. Only JavaScript is allowed, it seems that's all it takes to post here, at least using Firefox/Windows.

Anyway, using the updated exporter, I noticed that the UI was a bit streamlined (definite plus so far) along with some additional options; but, I also noticed some odd behavior. For one, it seems that while the exporter does create all the files necessary to start the render, it seems to be skipping some of the textures for the outfit when it goes straight into LuxRender itself. Now, I'm not entirely sure if LuxRender was started a little early before some of the material had finished writing to disk; but, I'm going to double check the material file and reload the program to be sure.

Any who, thanks to everyone for getting the Poser version of this exporter to work to this point!

Ugh... it seems that the materials for the outfit, unlike in the first export with the previous exporter, were skipped over and only the preview settings were applied. Before, it actually wrote out the textures and materials for everything that was secondary to the main figure. Hair looks fine. lol

Really odd behavior... I'm not sure I could be of any help, but I'll poke around the scripts to isolate where things are going odd. No promises though...

Quote - odf,

I was working with pydough and I found a couple problems. I don't remember if I successfully fixed them or how.

Problem 1: A prop hair parented to a figure was being exportered as part of a figure, as well as being exported as an independent prop. A parented hair answers to "ItsFigure" even though it isn't actually one of the figure's actors. This caused a bunch of missing texture warnings, because the copy exported as part of the figure was using the mat key for the figure, not the hair prop. I think I fixed it by filtering on "not IsProp()". But if that's what I did, it's a hack. Instead of iterating over all figures, it should just ask the figure for its actors. It think.

Problem 2: At some point, I was getting materials for two separate figures merged into one set of materials. I sort of remember this being the result of directly calling the exporter for actors even for figures. I can't really recall. Anyway, I think I changed to calling pydough to export a whole figure and that fixed it.  I think.

It's all fuzzy.

odf solved the problem with duplicate actors. Was just a mistake.
Because he is working on hair-export, especially hair will come into his focus.

All material problems coming from this are gone.

You are a bit behind, aren't you? :)

Quote - Ugh... it seems that the materials for the outfit, unlike in the first export with the previous exporter, were skipped over and only the preview settings were applied. Before, it actually wrote out the textures and materials for everything that was secondary to the main figure. Hair looks fine. lol

Really odd behavior... I'm not sure I could be of any help, but I'll poke around the scripts to isolate where things are going odd. No promises though...

Sometimes there is only a relative path in Poser while the textures are read from the material exporter.

Dizzi did an additional script (located in path "utilities") to fix some texture problems. 

FYI: No textures are copied. They are all left where they are. So you have to make sure Lux can access them.

I love your A3 with this blue hair :)

 Thanks Flenser :)

lol, thanks for the compliments on the hair. I'm also aware of the Lux's dependency to have correct path names to textures.

For the problem at hand, the odd thing is that the skin and hair look totally fine in the material export file, but it didn't write any of the information to the same file for the clothes. I guess what I'm trying to say is that relative or not, none of the texture and material information that's presented in Poser (7 on my end) are copied to the material file at the time of export in the same manner as the main figure's skin and hair. Only the preview materials seem to be copied. It also seems to be making invisible objects visible at export.

Example:
#----->   Figure 1/SkinTorso    <-----

# Color_Texture
Texture "ImageMap" "color" "imagemap"
"string filename" ["I:Data3D FilesExtra Poser ContentRuntimetexturesL75AIKO!L75AikoBody.jpg"]
"float vscale" [-1.0]
"float uscale" [1.0]
"float gamma" [2.2]

Texture "Color_Mul" "color" "scale"
"texture tex1" ["ImageMap"]
"color tex2" [0.8 0.8 0.8]

# Color_Texture
Texture "ImageMap_2" "color" "imagemap"
"string filename" ["I:Data3D FilesExtra Poser ContentRuntimetexturesL75AIKO!L75AikoBody.jpg"]
"float vscale" [-1.0]
"float uscale" [1.0]
"float gamma" [2.2]

Texture "Color_Mul_4" "color" "scale"
"color tex1" [0.000384473675505 0.000384473675505 0.000384473675505]
"texture tex2" ["ImageMap_2"]

Texture "Color_Mul_3" "color" "scale"
"texture tex1" ["Color_Mul_4"]
"color tex2" [0.8 0.8 0.8]

Texture "Color_Mul_2" "color" "scale"
"texture tex1" ["Color_Mul_3"]
"color tex2" [0.0333333015442 0.0333333015442 0.0333333015442]

MakeNamedMaterial "Figure 1/SkinTorso" "string type" ["glossy"]
"texture Kd" ["Color_Mul"]
"texture Ks" ["Color_Mul_2"]
"float uroughness" [0.135239918586]
"float vroughness" [0.135239918586]

And then the export data for one of the outfit pieces:
#----->   B25KDress/Preview    <-----

MakeNamedMaterial "B25KDress/Preview" "string type" ["glossy"]
"color Kd" [0.0395978799873 0.0288453555309 0.000899934645759]
"color Ks" [8.47378173458e-005 0.000629534320267 1.31898786232e-005]
"float uroughness" [0.100139605023]
"float vroughness" [0.100139605023]

Which currently results in the attached image.

And, I'm not sure if this matters, but I mentioned the previous render was using 0.1-2 (I think) and the current exported I used in this instance was 0.2.0 from BagginsBill's site. Maybe he changed something that no one else has check yet?

I thought bagginsbill said he really wasn't ready to have people test that yet?

If that's the case, since adp hasn't updated the latest build yet, it probably just isn't completely working with bb's gui (the one that he uploaded for the programmers to look at and not really for people to start using).

Laurie

@Synpainter: there is a bug in the current code (version alpha_1-20 as of this writing) which prevents calculation of normals for all props except the first one in the scene. That's what's causing the faceting you see. I've told ADP where the bug is (posted on the Peanut Gallery), but he must have overlooked my post or been too busy designing Skynet.

@bagginsbill:

0) If you refer to pydough, please get (or git, as the case may be) the latest version from http://github/odf/pydough first. I'm not going to debug obsolete versions, not even for you.

1) The problem with doubly exported props is fixed as of yesterday. I don't know about the material problems you mentioned, but since we don't export figures on a by-actor basis anymore, your info on that is probably outdated.

2) As for the coordinate transformation: it would be useful if you told me how you want this to be done (use a Lux transformation property or transform the coordinates directly) and then I'll either hardcode it in the GeometryExporter class or add an option to the initializer. I will keep working on the internals of that code, and you having to go in and modifying it each time is counter-productive.

Quote - I thought bagginsbill said he really wasn't ready to have people test that yet?

If that's the case, since adp hasn't updated the latest build yet, it probably just isn't completely working with bb's gui (the one that he uploaded for the programmers to look at and not really for people to start using).

Laurie

Oh well, I guess I jumped the gun a bit with my tests. Just trying to be more helpful than I was on the LuxRender forums.

Quote - @Synpainter: there is a bug in the current code (version alpha_1-20 as of this writing) which prevents calculation of normals for all props except the first one in the scene. That's what's causing the faceting you see. I've told ADP where the bug is (posted on the Peanut Gallery), but he must have overlooked my post or been too busy designing Skynet.

@bagginsbill:

0) If you refer to pydough, please get (or git, as the case may be) the latest version from http://github/odf/pydough first. I'm not going to debug obsolete versions, not even for you.

1) The problem with doubly exported props is fixed as of yesterday. I don't know about the material problems you mentioned, but since we don't export figures on a by-actor basis anymore, your info on that is probably outdated.

2) As for the coordinate transformation: it would be useful if you told me how you want this to be done (use a Lux transformation property or transform the coordinates directly) and then I'll either hardcode it in the GeometryExporter class or add an option to the initializer. I will keep working on the internals of that code, and you having to go in and modifying it each time is counter-productive.

odf: just a gentle reminder that adp is out of town currently ;o). Wasn't sure if you remembered or not...lol.

Laurie

thx fr render, wolf.  I was trying maxwell 1.1 on G4 in 2007.   didn't know how to use it
even unto the detail that it has to keep running to develop the exposure.  maybe I can
try luxrender (if OS X version) or maxwell, if they've got some free trial.

in re: enabling java in safari, it's a case where java is installed for the OS (e.g. OS X).
however, the issue of java (sun micro) and other items (adobe flash) being put on the ipad OS
may still not be set in stone.  steve jobs would have users adopt html5 and currently may
be stalling on allowing flash and java apps on said device.  I didn't read all of the above.

Quote - odf: just a gentle reminder that adp is out of town currently ;o). Wasn't sure if you remembered or not...lol.

I just wanted to point out that the ball is in his court now.

I've tried exporting stuff from Poser about 6 times now and I'm not having much luck here. Sorry, can't concentrate right now enough to edit the exported files as I've been reading in this thread (I had a tooth infection and a partial root canal done today). Could some one post some sort of demo scene for Lux that I can try to render while I wait for full material, light, and camera export???

I set this scene up to test materials, but I posted it because of the smoothness of the spheres. Seems people are having trouble with the Poser primitives, so I made the sphere in Wings 3D. I triangulated it before importing to Poser in AccuTrans (I like the way it triangulates better than Wings, which tends to make poles by making a lot of edges extend away from a single vertex).

The inset image is what the triangulated sphere looks like in Wings.

I'm not sure why the Poser primitives looks so awful and I'm not sure why my sphere looks better, but I thought I better post it for the programmers - maybe you gents know ;o).

Laurie

I was poking around with the sunsky light for an interior scene (which is a WIP, as evidenced by the mesh anomalies and lack of textures) in the attached image. I think it came out fairly well for just a lighting test.

I don't remember reading any more info on light portals here after its first mention, so I cheated a little bit by seeing what Blender does for them. It would seem that the only edit needed is to change the mesh's "Shape" tag(?) so it reads "PortalShape" instead. I don't think the UV section isneeded for portals, so that can probably be taken out as well if you want.

Oh, and thanks for doing all you've done LuxPose team!

the modeled geometry from blender also doesnt look always good in Lux.

i think its a mistake from Lux.

Quote - Hi guys, first time posting here. I haven't even really been doing anything with Poser lately, but I've been following this project from the shadows almost since it started.
 

I was poking around with the sunsky light for an interior scene (which is a WIP, as evidenced by the mesh anomalies and lack of textures) in the attached image. I think it came out fairly well for just a lighting test.

 

I don't remember reading any more info on light portals here after its first mention, so I cheated a little bit by seeing what Blender does for them. It would seem that the only edit needed is to change the mesh's "Shape" tag(?) so it reads "PortalShape" instead. I don't think the UV section isneeded for portals, so that can probably be taken out as well if you want.

 

Oh, and thanks for doing all you've done LuxPose team!

with portals its important that the normals are pointed in teh right direction. the normal must be pointed inside the room.

 @ odf

Thanks, I thought I was loosing it... :) 

@Laurie,

Just for giggles Can you try your ball image using just 1 infin light,  and then just 1 spot light... seems lights have some effect on how pronounced the facets look. although they never really go away. 

 Hi Baggins- you are looking in vain for Java - there is no Java on the ipad  :-(

Quote -  Hi Baggins- you are looking in vain for Java - there is no Java on the ipad  :-(

Does Java come as standard on any operating system?

I'm not looking for Java. I was responding to Kai's snide remark that I didn't bother to look for Java to enable my iPad to use the Renderosity post editor to make a post.

I don't see any problem with Poser's ball, at least Poser4 ball.
The three small balls are Poser4 ball and the big ball is a high poly sphere.
The only problem that Poser ball has is at the border where you can see that is not so round because it has too few polygons, beside this it looks as good as the hi res ball.

Don't ask me why the color of the floor in the mirror is not the same, I don't know.

I don't see any problems with the Poser ball, either.

 Hmm,

I dunno, I tried P6, P7 and P8 balls both low and high res versions and get the same results Facets

I  ran in Lux .7 and the new .8 (weekly  update)  with the 1.2 alpha exporter.

Must be me doing something wrong then... I'll try again when get home tonight.

Just for  the record:

iMac w/ OSX 10.5.8
Poser 8 (SR3)

Like I've said before, the faceting has nothing to do with the Poser primitives. It's a bug in ADP's code. Since I hear ADP is out of town, here's how you can fix it:

In the file workers/PoserLuxExporter_workers.py, find the line that goes

    normals = self.globalParameters.get("Geom").get("compute_normals", "true") == "true"

(line 460 in the current version alpha_1-20) and change it into

    normals = self.globalParameters.get("Geom").get("compute_normals", "true") in ["true", True]

In other words, take the '== "true"' bit at the very end and change it into ' in ["true", True] '. Don't change anything else in that file. In particular, don't change the indentation of that line.

Quote - Like I've said before, the faceting has nothing to do with the Poser primitives. It's a bug in ADP's code. Since I hear ADP is out of town, here's how you can fix it:

In the file workers/PoserLuxExporter_workers.py, find the line that goes

    normals = self.globalParameters.get("Geom").get("compute_normals", "true") == "true"

(line 460 in the current version alpha_1-20) and change it into

    normals = self.globalParameters.get("Geom").get("compute_normals", "true") in ["true", True]

In other words, take the '== "true"' bit at the very end and change it into ' in ["true", True] '. Don't change anything else in that file. In particular, don't change the indentation of that line.

Thanks odf,

I'll give this a go :),  My confusion came from Kawecki's posted image. 

Kawecki is using his own tool for getting geometries out of Poser and into Lux. That's why the faceting bug doesn't affect him.

 ;) hence my confusion....