strange things with tracegeometry()
-
THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED
On 26/03/2007 at 03:18, xxxxxxxx wrote:
Can you post a picture, I have problems to follow your description. thanks
cheers,
Matthias -
THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED
On 26/03/2007 at 05:18, xxxxxxxx wrote:
Okay, I'll try to.
Very simple setup, two planes, a floor and a light source. The lower plane has my shader in the transparency channel, the light has hard shadows enabled.
As you can see, as soon as the line "hits" the plane with my shader (assuming it renders pixels from left to right, as this only happens to pixels on the right of the plane), the shadow dissapears.
If I render a region that starts in a pixel that is in the shadow of both planes, the shadow of the opaque plane is gone. As soon as the renderer comes to a line that starts in the shadow of only the opaque plane (or no plane at all), the result is correct.
It gets better, I'm on a dualcore, so there are 2 rendering lines. As soon as any of the 2 renderlines start in a place that lies in the shadow of the opaque plane, but not the plane with my shader, *both* lines render the shadow correctly (limiting the program to one render thread does not change anything in the problem). That's why I think I might be overwriting something in memory or the volumedata or the initialisation - the problem depends on where I start rendering.
Sorry, it's a little complicated to describe this.
-
THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED
On 29/04/2007 at 16:41, xxxxxxxx wrote:
So I'm not making any sense at all?
Is there any example how I can make a call of tracegeometry() in a shader in the transparency channel without messing up the shadows?
-
THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED
On 23/07/2007 at 05:55, xxxxxxxx wrote:
I'm not giving up on this one. Sorry to be such a pest, but this is the strangest error I have ever encountered while programming.
I have rewritten the main part of the code in Cpp, as I thought this might be a problem in COFFEE. I run into the same problem as before (it's faster, though ;)).
I narrowed it down to this:
As soon as I call TraceGeonmetry() in a Shadow calculation (with a raydepth of 0, that is), this strange things start to happen. Thats why I tested for the ray depth in the code below, now there are no artifacts - but I don't get the nice shadow I'd like to get.So what can TraceGeometry() do wrong during shadow calculation, or how am I using it in a wrong way?
This is the code (now in c++), it's build from the SDKGradient-Example. In Color/Luminance-Channel this does exacly what I want it to do, the transparency itself looks good - only the shadow is broken.
#include "c4d.h" #include "c4d_symbols.h" #include "xdepth.h" struct DepthData { bool vd_available; }; //=============================================================================== class DepthClass : public ShaderData { public: DepthData ddata; public: virtual Bool Init(GeListNode *node); virtual Vector Output(PluginShader *sh, ChannelData *cd); virtual LONG InitRender(PluginShader *sh, InitRenderStruct *irs); virtual void FreeRender(PluginShader *sh); static NodeData *Alloc(void) { return gNew DepthClass; } virtual LONG GetRenderInfo(PluginShader* sh); }; //=============================================================================== LONG DepthClass::GetRenderInfo(PluginShader* sh) { return CHANNEL_RAYTRACING|CHANNEL_ALPHA_SUPPORT; } //=============================================================================== Bool DepthClass::Init(GeListNode *node) { BaseContainer *data = ((PluginShader* )node)->GetDataInstance(); return TRUE; } //=============================================================================== LONG DepthClass::InitRender(PluginShader *sh, InitRenderStruct *irs) { BaseContainer *dat = sh->GetDataInstance(); //get data ddata.vd_available = false; if (irs->vd != NULL) { ddata.vd_available = true; //volumedata available } return LOAD_OK; } //=============================================================================== void DepthClass::FreeRender(PluginShader *sh) { } //=============================================================================== Vector DepthClass::Output(PluginShader *sh, ChannelData *sd) { if (!ddata.vd_available) { return Vector(0.0, 0.0, 0.0); //in 2D preview just return black } Real depth = 0; //result variable if(sd->vd->raydepth != 0) //not calculating a shadow { SurfaceIntersection* si = gNew SurfaceIntersection(); Ray* testray = gNew Ray(*sd->vd->ray); testray->p.x = sd->vd->p.x; //use the surface point testray->p.y = sd->vd->p.y; testray->p.z = sd->vd->p.z; sd->vd->TraceGeometry(testray, 10000, 0, si); depth = Len(si->p - testray->p); gDelete(testray); gDelete(si); depth = 1 - depth/250; //change value to something that looks usefull in the render } else { depth = 0.5; //dont call tracegeometry here, or all hell breaks loose. ;) } return Vector(depth, depth, depth); //return value } //=============================================================================== Bool RegisterDepth(void) { // decide by name if the plugin shall be registered - just for user convenience String name=GeLoadString(IDS_DEPTH); if (!name.Content()) return TRUE; // be sure to use a unique ID obtained from www.plugincafe.com return RegisterShaderPlugin(1000001,name,0,DepthClass::Alloc,"xdepth",0); }
-
THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED
On 04/02/2008 at 03:59, xxxxxxxx wrote:
Hi,
I have a similar problem, did you get any answer to your request ? Or did you find a solution ?
Thanks,
Vincent
-
THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED
On 04/02/2008 at 05:12, xxxxxxxx wrote:
No, sorry.
I've given up so far, I have no idea what's wrong here.
But if you find a solution / have an idea, let me know - I'd still like to finish my shader.
-
THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED
On 05/02/2008 at 06:15, xxxxxxxx wrote:
Pickman, can you please describe what you want to achieve with your shader? thanks
cheers,
Matthias -
THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED
On 05/02/2008 at 08:43, xxxxxxxx wrote:
I was trying to render a scene with a glass teapot, filled with black tea. And I noticed (in the real world ), that depending on the volume of tea between an object and the camera, the colour varies from red-brown to a yellow colour (imagine a teaspoon in a cup of tea - at the top, near the surface, the tea is nearly completely transparent, and the more tea is between the spoon and the eye, more light is absorbed, and the colour changes).
So I wrote this shader that returns a colour depending on the distance between the point were the viewing ray hits the shaded object (the surface of the tea, for example) and the next thing that lies behind it in viewing direction (the spoon, for example).
Small distance = small volume = bright colour = transparent,
bigger distance = more volume = dark colour = less transparency.I tried it out, and it works just as I would expect when I use it in colour/luminance channel, and it even looks nice in the transparency channel:
Here's a small visualization of what I tried so far:
All's fine, except that a hard shadow casted by an object with this shader shows strange artifacts, like in the images in the posts above. If the shadow is casted by my shader alone, there is no problem. But as soon as there is another polygon between lightsource and shadow-catching surface, it doesn't work - I get this strange, jagged artifacts like in the posts above. And I have no idea why.
I calculate the distance with the tracegeometry() - funcion. I think i might kill *something* in the tracegeometry-call, because all works fine without this call (except i don't get the depth then, obviously).
-
THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED
On 08/02/2008 at 06:24, xxxxxxxx wrote:
I am not sure but I think you have to check manually if the object with your shader is shadowed by another object.
cheers,
Matthias -
THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED
On 08/02/2008 at 07:49, xxxxxxxx wrote:
That would kind of explain the shadow artifacts - kind of, because it all works well as long as i dont use tracegeometry(). Without that call, everything, including the shadows, is fine.
So it looks like I have to check for shadows as soon as I use tracegeometry()? can you give me a hint how i would do that?