VP camera clipping with non-perspective projection

Helper

On 09/03/2016 at 05:08, xxxxxxxx wrote:

Thanks for the list (output is indeed due to threading). Hmm, there's nothing indicating anything "wrong" or which one would assume causing any trouble. Changes in the direction seem to fit the line and column changes of the ray creation.

And sorry, I was a bit unclear: I meant to change the direction of the ray you pass to TraceGeometry(). But it doesn't seem detectable from the values so one cannot simply add a perturbation value.

Well, I am out of ideas for now I'm afraid. But would also be interested to know the outcome of this and if it is indeed a bug or at least what is causing this.

Helper

On 09/03/2016 at 05:45, xxxxxxxx wrote:

Thank you anyway, Katachi. Oh and about your idea of sligthly changing the direction of the ray, which
I forgot to address in my previous reply: Unfortunately I don't think that will be an option as the output
has to be very accurate. And it sounds very hack But I can give it a try at least.

Helper

On 09/03/2016 at 08:27, xxxxxxxx wrote:

Hello,

I still can't reproduce the issue here. Can you provide some simplified VideoPost code that reproduces the issue (without any third party functions etc.)?

Best wishes,
Sebastian

Helper

On 09/03/2016 at 13:02, xxxxxxxx wrote:

Hey Sebastian,

Yes, you can find a minimal example below. This is the result:

/**
 * Copyright (C) 2016  Niklas Rosenstein
 * All rights reserved.
 *
 * Demo plugin to reproduce second issue about the black pixels
 * in this PluginCafe Thread:
 *
 * https://developers.maxon.net/forum/topic/9383/12545_vp-camera-clipping-with-nonperspective-projection
 *
 * @file main.cpp
 * @created 2016/03/09
 * @lastmodified 2016/03/09
 */
  
#include <c4d.h>
#include <res/c4d_symbols.h>
  
class MyVideoPost : public VideoPostData {
public:
  
  static NodeData* Alloc() { return NewObjClear(MyVideoPost); }
  
  /**
   * Called to allocate additional buffers required by this videopost.
   * We allocate one new buffer for our rendering.
   */
  void AllocateBuffers(BaseVideoPost*, Render* render, BaseDocument* ) override {
    this->buffer_id = render->AllocateBufferFX(
      VPBUFFER_POSTEFFECT, "MyVideoPost", 32, true);
  }
  
  /**
   * Invoke our #DoRender() function after the actual rendering.
   */
  RENDERRESULT Execute(BaseVideoPost*, VideoPostStruct* vps) override {
    switch (vps->vp) {
    case VIDEOPOSTCALL_RENDER:
      if (!vps->open) this->DoRender(vps);
      break;
    }
    return RENDERRESULT_OK;
  }
  
private:
  
  /**
   * Called from #Execute() to render into the buffer allocated in
   * #AllocateBuffers() of which we saved the ID in #buffer_id.
   */
  void DoRender(VideoPostStruct* vps) {
    VPBuffer* buffer = vps->render->GetBuffer(VPBUFFER_POSTEFFECT, this->buffer_id);
    if (!buffer) return;
  
    Int32 const cpp = buffer->GetCpp();
    Int32 const line_width = buffer->GetBw() * cpp;
    AutoGeFree<Float32> line(NewMemClear(Float32, line_width));
    if (!line) return;
  
    Bool hit;
    Ray ray;
    RayHitID lhit;
    SurfaceIntersection si;
  
    for (Int32 y = 0; y < buffer->GetBh(); ++y) {
      ClearMemType<Float32>(line, line_width);
      for (Int32 x = 0; x < buffer->GetBw(); ++x) {
        vps->vd->GetRay(Float(x), Float(y), &ray);
        hit = vps->vd->TraceGeometry(&ray, LIMIT<Float>::Max(), lhit, &si);
        if (!hit) continue;
        line[x * cpp + 0] = 1.0;
        line[x * cpp + 1] = 1.0;
        line[x * cpp + 2] = 1.0;
      }
      buffer->SetLine(0, y, buffer->GetBw(), line, 32, true);
    }
  }
  
  /**
   * ID of the buffer that we allocate in #AllocateBuffers().
   */
  Int32 buffer_id = 0;
  
};
  
  
Bool PluginStart() {
  return RegisterVideoPostPlugin(
    234324 /* TEST ID! */, "MyVideoPost", 0, MyVideoPost::Alloc, "", 0, 0);
}
  
  
void PluginEnd() {
}
  
  
Bool PluginMessage(Int32 msg, void* pdata) {
  return true;
}

Thanks for looking into it.

Niklas

Helper

On 10/03/2016 at 09:22, xxxxxxxx wrote:

Hello,

with your code I can now reproduce the issue. But if I add the above snippet to adjust the start point the faulty pixels disappear. Can you confirm that?

  
// Adjust Starting Point  
if ((camType == CAMERA_PARALLEL) || (camType == CAMERA_AXONOMETRIC))  
{  
 ray.p    -= ray.v * 1000000.0;  
}  
  
hit = vps->vd->TraceGeometry(&ray, LIMIT<Float>::Max(), lhit, &si);

Best wishes,
Sebastian

Helper

On 10/03/2016 at 10:26, xxxxxxxx wrote:

Hello,

sorry I can not confirm that the faulty pixels disappear. The effect becomes stronger as described above.
I added the line directly without a check of the camera type beforehand:

        vps->vd->GetRay(Float(x), Float(y), &ray);
        ray.p -= ray.v * 100000.0;

Using your code instead doesn't seem to change the output, which makes sense since the perspective
projection is neither a parallel nor an axonometric projection, thus the ray position is not modified.

        Int32 camType = vps->vd->GetRayCamera()->type;
        if ((camType == CAMERA_PARALLEL) || (camType == CAMERA_AXONOMETRIC))
        {
            ray.p    -= ray.v * 1000000.0;
        }

Best,
Niklas

Helper

On 11/03/2016 at 05:39, xxxxxxxx wrote:

Hello,

what kind of system do you use to build and test the code?

Best wishes,
Sebastian

Helper

On 11/03/2016 at 06:35, xxxxxxxx wrote:

Hi Sebastian,

I use my own build system. But I have just pasted the code into a 100% fresh copy of the cinema4dsdk
Visual Studio project of Cinema 4D R16.050 and compiled it with VS2013 x64 (18.00.40418) and still
get the exact same result.

Regards,
Niklas

Helper

On 11/03/2016 at 07:40, xxxxxxxx wrote:

Hi Niklas,

my experience with VS2013 "msvc12" compiler, it got many pitfalls that produced wrong code many times.
I always rely on VS2012 compiler when calculations are intended, for VS2013 it is just memory handling.

Helper

On 11/03/2016 at 08:02, xxxxxxxx wrote:

Hello,

does it only happen with R16 or also with the current release (17.048)?

best wishes,
Sebastian

Helper

On 11/03/2016 at 08:17, xxxxxxxx wrote:

@Sebastian: I can indeed not reproduce this issue with R17.048. I have tested my original plugin in
the following configurations and combinations for which it didn't work are marked with an X.

R14 SDK | VS2013
```
[X] Cinema 4D R14
```
```
[X] Cinema 4D R15
```
```
[X] Cinema 4D R16
```
```
[  ] Cinema 4D R17
```
R16 SDK | VS2013
```
[X] Cinema 4D R16
```
```
[  ] Cinema 4D R17
```

So this seems to be a bug that has been fixed in R17? I can already read the unfortunate message in
my mind that there is no solution for this .

@Mohamed: Where did you experience such pitfalls? As mentioned, it works with VS2013 in R17, so
it doesn't seem to be a problem with the compiler, at least in this case.

Best,
Niklas

Helper

On 12/03/2016 at 00:56, xxxxxxxx wrote:

it happened with a FLIP simulator, produced an unknown crash, after long debugging it was the compiler.

Helper

On 12/03/2016 at 16:35, xxxxxxxx wrote:

At this point I wouldn't rule out VS2013 completely just yet. R17 is VS2013 compatible, but the others are compatible to older VS versions. So, it could be something fixed in R17 or an issue with older APIs with VS2013. Definitely check for both possibilities (until we hear something official).

Just to add: I am using VS2012 for R15 and R16 builds. If you have VS2012 installed, have you attempted builds for older version APIs using it?

Helper

On 14/03/2016 at 02:52, xxxxxxxx wrote:

Hello,

I contacted the developers to ask if there were any relevant changes between R16 and R17.

Best wishes,
Sebastian

Helper

On 16/03/2016 at 04:11, xxxxxxxx wrote:

Hello,

according to the developers there were no specific bugfixes for TraceGeometry() but many other bugfixes in the renderer that might influence the result. There are no know workarounds for the issue for Cinema versions older that R17.

Best wishes,
Sebastian