VP camera clipping with non-perspective projection

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