I can't get past the script file. Houdini issues me error message that sas platform undefined. Granted the author wrote it on SGI, but why would script syntax be different on Windows.

Also is there an internal global illum solution in Mantra. The window lights are not exactly working like area lights I am used to. Where are the shaders for area shadows found?

Thanx

Dave R

Hi David,

There is a quite interesting thread going on in the od forums about performing GI using VOPs - look in the VEX section at the “GI in VOPs” thread.

http://www.odforce.net/forum/ [odforce.net]

Hope this helps a little,
Jason.

Hi David,

Are you talking about Sean Lewkiw's Global Lighting tk script?

Open up the global.tk script file.
After all the comment lines (“#”) at the very top, you should see a line that like “set PATH /usr/home/global.cmd”. Here you just change your path to have something look like this “set PATH CProjects/global.cmd” for your windows machines. The important thing is that the global.tk script can find the global.cmd script.

After you have properly set the path for the global.tk script, open up Houdini and use HScript (Textport or Alt+shift+t) and type the follow command in there: tk CProject/global.tk (where ever your .tk file is located.)

I think this ought to work…

Mantra currently has no GI implementation. However, you can still cheat GI with Houdini's VEX. Unfortunately, that's not my area of specialty, so I won't get into that. Please follow Jason's link to OdForce and you should find some info there.


Take care,
Alex

My Houdini is in C:\Applicarions\Houdini_5_5_197\houdini
Thats where both the script and cmd file are located.

I specify the path, and all I get are path not set errors. The syntax is correct, I think.

Dave Riindner

Before you mention it.

I tried typing the path using both / and \ ways

Nothing works.

Unfourtunatly I am finding many unofficial tutorials on web for Houdini to always have some little detail missing, and many of them are written, well just plain badly. Its like the authors are saying, “Do what I mean, not what I write, and if I forget some small detail just go ahead and fill it in.”

They are written as poorly as RenderMan Companion and Advanced Renderman books are. Those two particullary make me angry at the authors. They continiously refer to Renderman Specification, and leave these huge chunks of empty information that has to be deduced. If I had Renderman Specification would I really need those books. The authors clearly know what they are writing about, but they don't know how to write.

When I wrote my formZ book, I left almost nothing out. In my tutorials I was very detailed, down to which options, and keystroke permutations. You cannot assume that the reader will be able to fill in the blanks.

Dave Rindner

Hmm… How weird…
It should work, technically speaking… I have gotten it to work before. (Unfortunately, my Houdini server is shut down now for vacation, so I can't run Houdini to retest)

Try this for the moment: put all your script (global.tk and global.cmd) on the root of C only. See if anything happen from there.

And remember, from within Houdini's textport, just type "tk /global.tk" (without the quote)


Beyond that… I just don't know what else to make it work…

Here how I've set it on my machine.(took me about 2 minutes)

I have a system variable HOME set to Cconfig/houdini
Furthermore. When run, Houdini uses this variable to create a directory called houdini5.5 which basically mimics the directory that is located in Houdini root directory and called houdini (except for some folders and files in this folder). Anyhoo. I've placed global.tk in to Cconfig/houdini/houdini5.5/scripts/tk8.0 and global.cmd in to Cconfig/houdini/houdini5.5/scripts/macro
Then, in global.tk, I edited the line which reads set PATH /usr/home/lewkiw/Scripts/global.cmd to read set PATH C:/config/houdini/houdini5.5/scripts/macro/global.cmd
and the line set PLATFORM $tcl_platform(platform) to read set PLATFORM pc


That's it!

Now since I have that HOME variable set I don't even need to type the full path in textport to get the script running. Just tk global.tk

You could also put these two files in to original Houdini root/houdini/scripts/tk8.0 and Houdini root/houdini/scripts/macro files and edit the global.tk file accordingly.

TheUsualAlex has it right. I just tried this and it works perfectly. You have to make sure that you read the instructions at http://www.lewkiw.com/html/global.html [lewkiw.com] carefully. Maybe you simply messed up your downloaded files? Create a new directory named chome and then redownload the scripts from that site to that directory. Change that single line in global.tk and it works. I didn't have to change the set PLATFORM line at all.

im having a problem..

…ive followed what everyone has said here on this thread - when i run in textport I get the following error message

———————————————————

Error in startup script:

can't use empty strng as operand of “+”
while executing
“expr $pINCR + 1”
(procedure “check” line 24)
invoked from within
“check”
(file “cmyhoudiniscripts/global.tk” line 414)



——————————–

obviously cmyhoudiniscripts/global.tk is where my cmd and tk file is kept…it finds it but cant run it - any help would be greatly appreciated

J

This method is pretty outdated by now anyhow. You can just put down a VEX Global Illumination SHOP and put in your HDR images there. The default ones from Debevec converted in the .rat format are available here:
http://odforce.net/codex/index.php?page=3&sec=other&catlimit=&sorty=&limit=5 [odforce.net]
(Debevec probes)

After that, create a single light at the world origin and assign this SHOP to it.

There's also a tutorial on this in the online help that comes with Houdini.

Hey edward

thanks for your reply…

I've been doing the whole GI thing in SHOP then putting it in a light at world level for a while now…also for HDRI - i was wondering about using this as a way of ‘faking GI’ and speeding things up

- or was this script an old method used before Houdini even had GI…and not really a speed up/way of making a dome array? - which is what i want to use it for.

Yes, the script was before mantra had GI. I thought that Ambient Occlusion is the almost the same idea as a light dome? For faster renders, it's probably easier to just use a debevec light probe and ambient occlusion in your VEX GI SHOP. And of course turning down the number of samples (try 64 first?).

I'm sure someone here can explain the differences between ambient occlusion and the light dome technique.

Light dome will often be much faster to get similar looking results. The Ambient Occlusion stuff is quicker to set up but (often) slower to render. Sean's tutorial was done before Digital Assets, really all you need now is a clever digital asset and then you just drop it in. I would think most major studios have Digital Assets that do the light dome technique automatically. We do at R+H however I can't share it (

Clever optimizations can be done so that you only cast shadows from lights above a certain intensity, and the depthmap shadows can be very low-resolution with heavy blur for speed of calculation.

Cheers,

Peter B

Light dome will often be much faster to get similar looking results. The Ambient Occlusion stuff is quicker to set up but (often) slower to render. Sean's tutorial was done before Digital Assets, really all you need now is a clever digital asset and then you just drop it in. I would think most major studios have Digital Assets that do the light dome technique automatically. We do at R+H however I can't share it (

Clever optimizations can be done so that you only cast shadows from lights above a certain intensity, and the depthmap shadows can be very low-resolution with heavy blur for speed of calculation.

One big problem right now with Mantra's Occlusion call is that it's hard-wired to sample 180 degrees across the shade point. What's really needed is the ability to specify the angle of sampling, very often you only need to sample 20 degrees or so to get a look that is similar, but by sampling a smaller angle you get much faster renders.

Cheers,

Peter B

Thanks guys..

…now its all clear.

Im just wondering - there are a few things that still puzzle me about Houdini and AmbOcc/GI/HDRI. ~( - this should probably be a new topic altogether )

So please be patient with a bit of a newbie alert!

1) Why is the ambient occlusion in Houdini a kind of dull grey - and whenever i see a render picture online from other Ambient Occlusion sources it is almost pure white with some dark occluded areas. Surely it should be more like this, as it is to calculate the occluded areas?

2) Using HDRI in a GI Shop - does this mean that it can theoretically replace all lighting, so you dont need any extra lights at all? - so…all image based calculations can be made from this as an environment map?
Or would u instead use it as a ambient environment (a pass for compositing?) to be combined with lights as well? Or can both these kind of things be done…what is common production practice?

3)Also - how do you know that the HDRI map is orientated the right way? I am guessing that is down to taking original photos of the reflective ball in the direction the camera is facing - but what about when camera moves are implemented?

4) how is ambient occlusion or HDRI implemented at the compositing stage? I assume it is multiplied by the diffuse pass, or is there other methods?


Anyway - sorry for such basic questions, they are just things that are nagging me at the moment.

Any comments would be much apprecated

Thanks again

J


PS - hey ed. Are you the same ed from odforce.net/forum? Cheers if u are, you have been very helpful with my questions

Some partial answers.

1) Maybe it's because the image rendered is not gamma corrected? If you set mplay to use a 2.2 gamma, does that look like it?
2) Yep. But as you guessed, you can combine this with other lights at the same time as well. Can't really comment on common practice …
3) I suppose one way is to render a sphere with the HDRI map in your VEX Metal SHOP. Set Reflect to (1,1,1) and for the other colours, use (0,0,0).

(yes, same edward)

JohnnyBGoode
1) Why is the ambient occlusion in Houdini a kind of dull grey - and whenever i see a render picture online from other Ambient Occlusion sources it is almost pure white with some dark occluded areas. Surely it should be more like this, as it is to calculate the occluded areas?

My guess is that the reason occlusion is showing up grey is because it's giving you the total amount of energy arriving at a point on the surface (“irradiance”) out of *all* the available energy in the environment. Any point on a directed surface can at most “see” half of the full sphere of directions (a hemisphere). So that if there was 4PI units of energy available, a typical point on a surface will be able to receive at most 2PI units, which, in terms of total available energy, would be 2PI/4PI = 1/2.

The images you're used to seeing show the complement of “percent occlusion” – which I guess one could call “exposure” – and have nothing to do with irradiance: it's just a measure of “exposure”; i.e: an unoccluded point is totally “exposed” and so shows up as white. As an aside, note that if your environment is nothing more than a constant white color, then you can multiply (brighten) the grey image you're currently getting by 2 to get the result you're used to seeing.

VEX has a variant of the occlusion() function which computes percent coverage (as you're used to seeing) and also throws in the famous “bent normal” at no extra charge
To try it out, create a “VEX Surface Shader” network in VOPs, go inside it and add an Inline VOP. In the Inline VOP, create a Float output called “occ” and a Vector output called “bent”. In the “Inline VEX Code” field enter the expression occlusion($occ,$bent,P,N);. Finally, pipe the “occ” output to a FloatToVector VOP and wire that to Cf. This shader would now give you the results you're used to.

@SESI: Maybe this version of occlusion should be made available in VOPs, no?

Cheers!