VolumeData::GetNormals() always crashing! [SOLVED]
-
On 03/03/2015 at 13:43, xxxxxxxx wrote:
Hi MohamedSakr,
Thanks for sending me those values, it gets me a bit closer to resolving your problem.
Sorry for asking about vfeld, it's normal you couldn't find it. I don't know what value it might have, but considering the code I see, it shouldn't be a factor. Otherwise, your code wouldn't be crashing, and instead returning all zeros in the PolyVector.
All the other values you gave me allowed me to narrow down which line is causing the crash. Long story short, it's not making sense that flag_phong is set to a non-zero value, yet op->psum is equal to nullptr, regardless of the value of phong_angle, as the latter only determines which block of code is executed, but both assume op->sum is non-zero.
Therefore, are you doing anything to set op->psum? Alternatively, are you setting flag_phong to 1 somehow without actually setting up the phong data in RayObject? Since it's a struct, there's no way of stopping incorrect or incomplete combinations from being set amongst its data values. That's what stops me from being able to go any further, as I have no idea how you're setting up this data.
Joey Gaspe
SDK Support Engineer -
On 03/03/2015 at 14:19, xxxxxxxx wrote:
no, not any of this, i just looping over RayObject* to convert their data to my render engine DLL, and here is the data that I think it may be important;
plugin is VideoPostData plugin.
register flag is PLUGINFLAG_VIDEOPOST_ISRENDERER
Cinema4D version R15
a very simple scene, just a cube object.
I didn't set any flags to anything in the RayObjectand lastly it executes here:
if (vps->vp==VIDEOPOSTCALL_RENDER && vps->open) { vps->vd->SkipRenderProcess(); for(Int32 i = 0; i < vps->vd->GetObjCount(); ++i)//iterate over polygon objects { RayObject *op = vps->vd->GetObj(i); if(op->type == O_POLYGON) { if(op->psum) GePrint("psum is NOT nullptr"); if(op->vadr) { GePrint(" a: " + String::IntToString(op->vadr[0].a)); GePrint(" b: " + String::IntToString(op->vadr[0].b)); GePrint(" c: " + String::IntToString(op->vadr[0].c)); GePrint(" d: " + String::IntToString(op->vadr[0].d)); } GePrint(" flag phong: " + String::IntToString(op->flag_phong)); GePrint(" phong angle: " + String::FloatToString(op->phong_angle)); } } }
-
On 03/03/2015 at 14:48, xxxxxxxx wrote:
Hi MohamedSakr,
Thanks for your reply, the info allowed me to find a potential reason. The key thing is that you don't mention anything about setting up phong shading itself. I double checked the code and ran through it in the debugger: There's a phong tag has to be set up on your cube for the flag_phong flag to be set to true, but you don't mention it.
Joey Gaspe
SDK Support Engineer -
On 03/03/2015 at 14:49, xxxxxxxx wrote:
I edited previous reply, check some code, and the phong tag is on the cube, just created the cube and hit render.
-
On 03/03/2015 at 14:54, xxxxxxxx wrote:
Hi MohamedSakr,
I didn't see your edits until after I submitted my previous post. In that case, if you're setting up the phong tag, then I'll dig deeper as to why the value in question is null.
Joey Gaspe
SDK Support Engineer -
On 03/03/2015 at 15:05, xxxxxxxx wrote:
for some reason, if I changed VIDEOPOSTCALL_RENDER to VIDEOPOSTCALL_INNER it works, but I'm not sure what to do when flag VIDEOPOSTCALL_RENDER rises to stop some shader pre processing? just skipping?
-
On 03/03/2015 at 15:13, xxxxxxxx wrote:
Hi MohamedSakr,
I discovered that if you have a phong tag, but want normals, you need to also set up a NormalTag. Do you set up a normal tag too? The code indicates that you must so that psum is actually allocated data.
Joey Gaspe
SDK Support Engineer -
On 03/03/2015 at 15:29, xxxxxxxx wrote:
no I didn't set a NormalTag
I think GetNormals name is miss leading, it means GetNormalShading "or shading normal" , while GetNormal gets the geometric normal. -
On 04/03/2015 at 08:18, xxxxxxxx wrote:
Hi MohamedSakr,
I agree it's misleading, but at least now you know! Did creating a normal tag solve your problem?
Joey Gaspe
SDK Support Engineer -
On 04/03/2015 at 08:23, xxxxxxxx wrote:
actually no , in a previous comment I said it is solved when I changed VIDEOPOSTCALL_RENDER to VIDEOPOSTCALL_INNER
consider this solved, VIDEOPOSTCALL_INNER should be used!!
-
On 04/03/2015 at 10:28, xxxxxxxx wrote:
Hi MohamedSakr,
OK, as long as your problem is solved, good stuff! I'll close the topic as such.
Joey Gaspe
SDK Support Engineer