strange things with tracegeometry()

THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED

On 25/03/2007 at 16:33, xxxxxxxx wrote:

User Information:
Cinema 4D Version:   9.1 
Platform:   Windows  ;   
Language(s) :   C.O.F.F.E.E  ;

---------
Hi there!

I'm running into some rather strange things with a channelshader I'm writing. I use tracegeometry() to shoot a ray to calculate the "volume" of the material in the rays direction (basically, the distance to the nex hit on anything). In the color- or luminance channel that works fine, I get a nice "depth map", as I'd expect it. But in the transparency channel some very strange things happen with shadow calculation.

It seems that whatever I use in the tracegeometry-call kills something for the rest of the rendering process of that thread (or at least line) - if that makes any sense. It's a little hard to describe, but depending of whether or not the rendering line crossed a pixel that lies in the shadow of a plane with my shader on, I get different results, even if I don't actually use the result of tracegeometry.

I hope that made any sense at all. ;)

The code is basically copied from the coffee - SDK.

  
MyChannel::Output(settings,rd,p,n,d,t,texflag,vd)  
  
(some tests if vd exists at all)  
  
var resultp, resultn;  
var myray = new(Ray);  
myray->p = vd->p;     //ray origin  
myray->v = vd->v;     //...direction  
myray->pp0 = myray->pp1 = myray->pp2 = myray->p;     // fill mip variables  
myray->vv0 = myray->vv1 = myray->vv2 = myray->v;     // fill mip variables  
myray->ior = 1.0;  
var id = vd->TraceGeometry(myray, 10000, 0, &resultp;, &resultn;);  
  
(calculate distance from resultp, etc.)  
  
return (calculated value)  

It looks like sometimes the renderer only checks from the point it's just calculating the shadow for up to the polygon with my shader, but then ignores any other stuff between the polygon with my shader and the light source. I'd thought I only have to calculate a transparency value, and the renderer will make the actual ahadow calculation by itself? Or do I really have to manually trace rays up to the light source...?

I'm probably doing/forgetting something really stupid, but what? ;)

Thanks!
-Timm

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?