Relations: BaseObject,RayObject,OPolygon [SOLVED]

Helper

On 17/10/2014 at 06:14, xxxxxxxx wrote:

Hi FrozenTarzan,

I'm glad that cleared things up for you. I know it means there isn't an easy way out, but you were already on the right track. Sure, let us know if you have any issues, I know turning a sphere into a polygon probably means a lot more data is created than otherwise would have been necessary.

Thanks for replying back,

Joey Gaspe
SDK Support

Helper

On 17/10/2014 at 11:55, xxxxxxxx wrote:

It took me only a few minutes to run into a problem^^

When a user places a sphere into the scene, then this sphere is a parametric one (not editable). This sphere is treated specially, as we discussed earlier and is of type O_SPHERE in the raytracer. So my plan was to ignore it and handle spheres on my own by cloning them and making them editable, so in some sense bake everything so that I can access tags, vertices and so on. This would work, but when the user adds deformers to the spheres, the raytracer (of course) has to use polygons again, and so they disappear as RayObjects of type O_SPHERE and are RayObjects of type O_POLYGON.

Another fantastic image to make it clear

So it's simple: When I disable the deformers, the spheres are O_SPHERE and when I enable them they are O_POLYGON.

This behavior is really understandable, but I must find a way to work around it. Everything would be solved if I could get a link to the original object in the hierarchy. Then I would know that a O_POLYGON was originally a sphere, so I could tell my own algorithm that it should not export the sphere (by cloning, baking,...) because it already was transformed by C4D for me.

Does anyone have an idea to get such link? The link is, as discussed, always nullptr for O_SPHERE RayObjects. I really don't know why. It would be great if a developer could name a reason for this.

Helper

On 17/10/2014 at 12:59, xxxxxxxx wrote:

I'm not sure where is the problem, but from what you say:
if it has active deformers, then the type will be O_POLYGON, and if it hasn't then the type is O_SPHERE

what about dynamic casting? if it is O_POLYGON then pass it, if it is O_SPHERE then process it with your own bake methods

Helper

On 17/10/2014 at 21:17, xxxxxxxx wrote:

Hmm... I don't want to be mean, but from what I wrote in the whole thread, it should be clear, that there is no way to dynamic cast a RayObject to anything else, because there is no inheritance hierarchy.

And as we discussed earlier, it is not possible to get to the polygons of a O_SPHERE, because it has none, so my plan was to export a polygonized version of the Osphere (!) which is a BaseObject, not a RayObject. The problem is that I don't have the link to the original object, so I cannot tell if a O_POLYGON RayObject was a sphere originally, in which case I would not have to do the cloning thing.

Helper

On 17/10/2014 at 21:19, xxxxxxxx wrote:

Oh, and yes I could check the sphere in the object hierarchy for deformers, but I would have to be sure that this is the one and only thing where C4D transforms a parametric sphere into a polyogonized version automatically. There might be tags or other mechanisms that do the same. So if I cannot guarantee that only deformers do that, my code will not be stable in any circumstances.

Helper

On 18/10/2014 at 02:57, xxxxxxxx wrote:

well sorry for this , wasn't reading the whole thread, now I understand a little more about how they inherit

about:
"So it's simple: When I disable the deformers, the spheres are O_SPHERE and when I enable them they are O_POLYGON.

This behavior is really understandable, but I must find a way to work around it. Everything would be solved if I could get a link to the original object in the hierarchy. Then I would know that a O_POLYGON was originally a sphere, so I could tell my own algorithm that it should not export the sphere (by cloning, baking,...) because it already was transformed by C4D for me."

I sense I don't understand this part, if there is no deformers, then it will be O_SPHERE , where you will handle it by your own methods, now if there is deformers, then it will be O_POLYGON with all of its data ready for you, I can't figure out where is the problem here "may be I'm missing something"

Helper

On 18/10/2014 at 03:08, xxxxxxxx wrote:

unless you want to process the O_SPHERE as triangles, and from this thread I can see that Cinema 4D won't give you this data

a possible solution, is to compare all O_SPHERE objects with the object hierarchy "spheres" transformation matrix 4x4 + radius, so you can guarantee that they are exactly the same object (but this may fail if you have multiple spheres with the same radius at the same location, where they have different types "e.g. Tetrahedron, ..." but this seems to be a near impossible case)

another solution (which would be much better!!) , is:loop over all spheres on object hierarchy, and turn off "render perfect" , I think this should force them to be O_POLYGON

Helper

On 19/10/2014 at 12:43, xxxxxxxx wrote:

Regarding the deformers, I posted my thoughts above:
"Oh, and yes I could check the sphere in the object hierarchy for deformers, but I would have to be sure that this is the one and only thing where C4D transforms a parametric sphere into a polyogonized version automatically."

The hint about "render perfect" sounds promising. I will try that tomorrow!

Helper

On 20/10/2014 at 05:38, xxxxxxxx wrote:

Hey Mohamed, thanks a lot, it works!

Here's the code I use now to treat spheres as PolygonObjects. When "render perfect" is turned off, they are all converted to O_POLYGON RayObjects, so the rest of my code works as is

// for each BaseObject in hierarchy:
if (pObject->GetType() == Osphere)
{
    BaseContainer* baseContainer = pObject->GetDataInstance();
    if (baseContainer != nullptr)
    {
        bool renderPerfect = baseContainer->GetBool(PRIM_SPHERE_PERFECT);
  
        if (renderPerfect)
        {
            GePrint("Parametric sphere found! Turing off \"render perfect\"!");
            baseContainer->SetBool(PRIM_SPHERE_PERFECT, false);
        }
    }
}

Thanks again, this made my day!

Helper

On 20/10/2014 at 06:02, xxxxxxxx wrote:

glad that it worked , but when do you call this function? "I think I will face the same problem at some point in my render engine, and I need to call the function before Cinema 4D data filling"

Helper

On 21/10/2014 at 03:14, xxxxxxxx wrote:

I call it in the Execute function of my VideoPostData plugin:

RENDERRESULT MyVideoPostDataPlugin::Execute(BaseVideoPost* node, VideoPostStruct* vps)
{ if (vps->error == nullptr || *vps->error != RENDERRESULT_OK || vps->thread->TestBreak()) { return RENDERRESULT_OK; } if (vps->vp == VIDEOPOSTCALL_FRAMESEQUENCE && vps->open) { C4dHelper::foreachObjectInHierarchy(vps->doc, vps->doc->GetFirstObject(), [&](BaseObject* pObject) -> bool { if (pObject->GetType() != Osphere) return true; BaseContainer* baseContainer = pObject->GetDataInstance(); if (baseContainer == nullptr) return true; if (!baseContainer->GetBool(PRIM_SPHERE_PERFECT)) return true; GePrint("Parametric sphere found! Turing off \"render perfect\"!"); baseContainer->SetBool(PRIM_SPHERE_PERFECT, false); return true; }); return RENDERRESULT_OK; } if (vps->vp == VIDEOPOSTCALL_INNER && vps->open) { // RayObjects of type O_SPHERE should not have been created now, // instead they are of type O_POLYGON return RENDERRESULT::RENDERRESULT_OK; } return RENDERRESULT::RENDERRESULT_OK; }

Helper

On 21/10/2014 at 04:25, xxxxxxxx wrote:

well thanks a lot , but I'm kinda confused now, what I understand is that videopost plugin is called "after" Cinema 4D ray object filling, so how this is working before the filling?

Helper

On 21/10/2014 at 06:21, xxxxxxxx wrote:

Search in the docu for these flags:
* VIDEOPOSTCALL_FRAMESEQUENCE
* VIDEOPOSTCALL_INNER

There are some more of those, where each is called in a fixed order with an open or close bool.

Execute is called for each step in the rendering pipeline twice. The VIDEOPOSTCALL_FRAMESEQUENCE is the first one before a rendering starts and before C4D performs any computations. VolumeData, for example, is not ready in this state, so setting the "render perfect" works

Helper

On 21/10/2014 at 06:24, xxxxxxxx wrote:

oh , thanks a lot for clarification