Trace related functions and SOP context

[hoknamahn]

Hi all!

Seems that all trace related functions such as rayhittest, trace, occlusion, irradiance etc., etc. are unavailable in SOP context. Which algorithm can replace, for example, rayhittest function? (of course in SOP context)

[TheDunadan]

Haven't done anything alike in Houdini yet, but I think I read somewhere in the doc that you can bake shaders to files. Baking these is likely the easiest way to get those informations into SOP context.

Besides there is the ray SOP that can be used to emulate some trace functions.

If you want to write a plugin to rewrite those trace function for SOP context you'll likely run into a few problems, but most of these algorithms can be found in books such as: An Introduction to Ray tracing or Advanced Animation and Rendering Techniques

Besides there is google

Part of the trouble of rewriting the algorithms for SOP context will be the following: When rendering an image we usually send the rays from the virtual camera into the scene and by adjusting the resolution of the image we directly influence how often and where we do the tracing.

If you want to do this on a SOP level you need to manually define your sampling points. Possibly the new scattering function will be of great use here, since doing those things on a per vertex / face level is likely to cause pretty inaccurate results unless you start with a high polycount in the first place.

Haven't had the chance to play with point clouds so far, but if we can permanently store any informations in those points and can call/evaluate any shader function on these + save the data for SOP context, there is likely no need to rewrite those algorithms.

Jens

[Jason]

In the SOP context there is still intersect() - which casts a ray through geometry read in. Don't forget that instead of going to a BGEO on disk, you can use the "op:/" syntax and refer to a SOP directly - most often the SOP in the chain above you.

"op:"+opfullpath("../"+opinput(".",0))

If you need more help, write in here:)

[hoknamahn]

Thanks, Jason

I still think, does the game is worth the candle, there will be vertex occlusion more rapid than the ordinary occlusion, using point clouds.

By the way, how to look up a sample from the environment map if I have an "average light direction" (or "bent" normal)? Can I use this function?

vector environment(string map; vector D)

I tried it but result is strange. Very strange... especially if compare with occlusion() function with parameter "environment".

And which algorithm is used in emdedded occlusion function? Is it use a bent normals?

This form of occlusion function

void occlusion(float &coverage, vector &missed_direction, [options])

gives me what I want but I must (???) to look up environment separately?

And what means "width" parameter in occlusion or irradiance functions? Is it a filtering related parameter?