VP camera clipping with non-perspective projection
-
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 -
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 -
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 -
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. -
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 -
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 -
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.
-
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?
-
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 -
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