3DRender.com's lighting challenges

[Jason]

Hi there,

How many people here take part in the Lighting Challenges from Jeremy Birn? I'm impressed that they distribute Houdini Apprentice archives of the scenes now, which make it a lot easier to get started.

Cheers,

Jason

[Matt_K]

Hi Jason,

I have also used some of the OBJs - for testing different lighting / rendering options in Houdini - and they work very nicely.

It's a great resource and well worth a look.

Matt.

[edward]

I think a Houdini user supplied the .hipnc file for that latest lighting challenge. It was probably converted over from the FBX file?

http://forums.cgsociety.org/showpost.php?p...mp;postcount=40

[Wolfwood]

How this latest scene is pretty nice.

Its definitely a great resource for people who want to focus on lighting and not get bogged down modeling their own scenes.

[michael]

there is a new Lighting Challenge at 3drender.com > http://www.3drender.com/challenges/index.htm "The King's Treasure"

I have downloaded the OBJ file and fixed it up a bit:

deleted the bazillion groups that maya spits out for every damn polygon

made new, hopefully, more useful and sensible primitive groups

fixed all the normals

saved it as a .bgeo file = 13mb vs 28mb for the obj

so just whack down a file sop and feed it the bgeo

I'll try to go through the other files and do the same over time...(but if you want to help out that would be awesome - just let me know)

I've sent the file to Jeremy Birn so it should be up there soon.

Have Fun!

[Jason]

Time to make nice and have fun with the PBR and IPR enhancements!

Thank you Mr Goldfarb!

EDIT: Gah! It's all gems and stuff.. The PBR glass shader doesn't have the goodies for gem stones. Raytracing and Mario's glass shader is the way forward, I suppose. I'm torn...

[edward]

I have downloaded the OBJ file and fixed it up a bit:

That's interesting. I would have thought you just loaded the Maya file and exported it to FBX or use Core's custom bgeo exporter.

[Mario Marengo]

EDIT: Gah! It's all gems and stuff.. The PBR glass shader doesn't have the goodies for gem stones. Raytracing and Mario's glass shader is the way forward, I suppose. I'm torn...

Nah, you can still do some hacky dispersion with PBR, just ask Anamous

I say PBR!! (I confess I've been having lots of fun with it lately).

Looks like a fun contest. Thanks for the heads up, Michael!

[jason_slab]

Nah, you can still do some hacky dispersion with PBR, just ask Anamous

I say PBR!! (I confess I've been having lots of fun with it lately).

for H10?

jason

[michael]

That's interesting. I would have thought you just loaded the Maya file and exported it to FBX or use Core's custom bgeo exporter.

I thought of that but I didn't want to have to deal with our stupid scripts...

plus I would have had to clean the thing up anyway....

it doesn't look like it's on the site yet...if it's not there by the end of the day I'll put a link in this thread...

[michael]

the bgeo file is now on the download page:

http://www.3drender.com/challenges/index.htm

[anamous]

Jason, if you consider PBR with the dispersion shaders that Mario mentioned, be prepared to experience a whole new dimension of SLOW. But I was thinking the other day and I thought I'd bounce this off you guys (specially Mario) - it should be possible to fake it. Now that message passing and manual ray shooting works in PBR (gather() etc.), we should be able to trace using the bsdf trace() and also shoot one extra manual ray to find out

- the distance to the next hit that is not the same shader

- the amount of deviance of the transmission ray from the incident ray (angle between T and I)

- and the normal at the hit point

and using this info we should be able to calculate a lookup either using Mario's spectral conversion functions or a simple spectrum texture. Then we tint the transmission result using that lookup. This approach in theory would work for most cases (except for when the shader hits itself on a different object, but that could be checked for, too) and render cost would be one transmission ray and one auxiliary ray - a lot less than the current sampling mechanism for dispersion.

I'll try and find some time this weekend to test the approach.

cheers,

Abdelkareem

[michael]

er...

let me know where you want this post moved

[Netvudu]

how about moving it to Alaska?

...am I banned?

Edited May 8, 2009 by Netvudu

[Mario Marengo]

Jason, if you consider PBR with the dispersion shaders that Mario mentioned, be prepared to experience a whole new dimension of SLOW. But I was thinking the other day and I thought I'd bounce this off you guys (specially Mario) - it should be possible to fake it. Now that message passing and manual ray shooting works in PBR (gather() etc.), we should be able to trace using the bsdf trace() and also shoot one extra manual ray to find out

- the distance to the next hit that is not the same shader

Or perhaps a little cheaper (saving one extra trace) if you could use the length of I directly (for attenuation)... iff one could come up with a way to determine that the segment {Eye,Eye+I} lies entirely inside the glass (message passing perhaps?).

- the amount of deviance of the transmission ray from the incident ray (angle between T and I)

- and the normal at the hit point

and using this info we should be able to calculate a lookup either using Mario's spectral conversion functions or a simple spectrum texture.

I wasn't aware that there was a bsdf trace(). Where did you see that? (I just looked at "vcc -X surface | grep trace" as well but I don't see it).

I also confess I haven't tried message passing in PBR, but I'll take your word that it works, which is awesome!). If that's the case, then you should be able to embed the wavelength into the ray itself, which can be picked up and used by the same shader. That is, you shouldn't need any of the geometrical bits (like the angle between T and I and such).

Can you give a brief description of how you're doing message passing in PBR? (as I said, I haven't tried it yet, so I'm a bit behind the times when it comes to PBR).

Cheers.

[anamous]

I wasn't aware that there was a bsdf trace(). Where did you see that? (I just looked at "vcc -X surface | grep trace" as well but I don't see it).

My stupidity. I was thinking in VOPs... I actually meant specular() which is can be used for the main ray...

I also confess I haven't tried message passing in PBR, but I'll take your word that it works, which is awesome!). If that's the case, then you should be able to embed the wavelength into the ray itself, which can be picked up and used by the same shader. That is, you shouldn't need any of the geometrical bits (like the angle between T and I and such).

You're absolutely right!

Can you give a brief description of how you're doing message passing in PBR? (as I said, I haven't tried it yet, so I'm a bit behind the times when it comes to PBR).

I can confirm that it works at least in sending direction via the usual gather(P,D,"send:something", something) mechanism, but retrieving return values is a bit... non-working. however, I have another stupid plan for that.. abusing point cloud files as "shared memory" between the shaders. don't laugh

cheers,

Abdelkareem

[Mario Marengo]

My stupidity. I was thinking in VOPs... I actually meant specular() which is can be used for the main ray...

Ah, OK. That makes sense.

I can confirm that it works at least in sending direction via the usual gather(P,D,"send:something", something) mechanism, but retrieving return values is a bit... non-working. however, I have another stupid plan for that.. abusing point cloud files as "shared memory" between the shaders. don't laugh

Heh. No reason to laugh since I've been known to use them for that purpose myself (and so has Wolfwood); it's a more common use for pointclouds than you think. Have a look at this thread where both the pc method and another DSO method are mentioned.