Q about RenderDocument(), custom Renderer [SOLVED]

Helper

On 13/01/2015 at 01:03, xxxxxxxx wrote:

Hi Joey,

your answer helped me a lot!! !Tongue[URL-REMOVED] , you are true about my usage of PLUGINFLAG_VIDEOPOST_ISRENDERER in registering.

about the question of Bitmap filling:
I don't use any render layers of Cinema 4D "I will fill my own layers by my Renderer, and save them, what I just want is:show the result "I can do this manually without using the Bitmap* , but I wanted to know what happens in that pointer so I disable it if it consumes processing power, or use it if it is useful.

[URL-REMOVED] @maxon: This section contained a non-resolving link which has been removed.

Helper

On 13/01/2015 at 10:19, xxxxxxxx wrote:

Hi MohamedSakr,

Thanks for letting me know the answer helped! The command in your code should already be skipping the rendering process, in terms of saving computing power:

vps->vd->SkipRenderProcess();

Again, with CineMan as an example, it uses the above call in its render code.

Thanks for the clarification for question 2! As for the RenderDocument() bitmap itself, there's nothing you can do to indicate you don't need it to be used for render output. The whole process is built around the bitmap being the output of everything RenderDocument() is going to do.

Joey Gaspe
SDK Support Engineer

Helper

On 13/01/2015 at 10:24, xxxxxxxx wrote:

if I pass a nullptr to the function Bitmap argument, will it work? or it will return early before calling Execute()?

Helper

On 13/01/2015 at 11:02, xxxxxxxx wrote:

Hi MohamedSakr,

What I just found, in code that exports shader data, is that you have to indicate not to save the image but still have to pass a bitmap to RenderDocument(), and just ignore it, like the following, in your Execute() function:

  
RenderData* rd = doc->GetActiveRenderData();  
  
if (!rd)  
  return FILEERROR_OUTOFMEMORY;  
  
// Indicate you don't want it to save the image  
BaseContainer* rData = rd->GetDataInstance();  
Bool hasSaveImage = rData->GetBool(RDATA_SAVEIMAGE);  
rData->SetBool(RDATA_SAVEIMAGE, false);  
  
// Must create a bitmap anyway, can't pass nullptr or anything equivalent  
AutoAlloc<BaseBitmap> bmp;  
if (!bmp)  
return FILEERROR_OUTOFMEMORY;  
  
// Must initialize the bitmap even if it's useless  
bmp->Init(rd->GetDataInstance()->GetInt32(RDATA_XRES), rd->GetDataInstance()->GetInt32(RDATA_YRES));  
  
RenderDocument(doc, rd->GetData(), nullptr, nullptr, bmp, RENDERFLAGS_EXTERNAL, nullptr);  
  
// Setting back to save images a good idea  
rData->SetBool(RDATA_SAVEIMAGE, hasSaveImage);  
  
// Don't use bmp for anything at this point, instead your own code

I think that's what you need. Please let me know if it works, as I chopped out some parts that seem specific to the situation.

Joey Gaspe
SDK Support Engineer

Helper

On 13/01/2015 at 11:11, xxxxxxxx wrote:

Hi Joey,

thanks for clarification and code snippet, I guess I know what to do now, consider this solved

Helper

On 13/01/2015 at 11:24, xxxxxxxx wrote:

Hi MohamedSakr,

Thanks for letting me know! Yes, indeed solved!

Joey Gaspe
SDK Support Engineer

Helper

On 21/01/2015 at 06:12, xxxxxxxx wrote:

sorry for opening this again, but I think I must know how the Bitmap is filled, this is essentially for the MaterialData plugin preview image, code from SimpleMaterial.cpp example

  
		case MATPREVIEW_GENERATE_IMAGE:
		{
			MatPreviewGenerateImage* image = (MatPreviewGenerateImage* )data;
			if (image->pDoc)
			{
				Int32					w = image->pDest->GetBw();
				Int32					h = image->pDest->GetBh();
				BaseContainer bcRender = image->pDoc->GetActiveRenderData()->GetData();
				bcRender.SetFloat(RDATA_XRES, w);
				bcRender.SetFloat(RDATA_YRES, h);
				bcRender.SetInt32(RDATA_ANTIALIASING, ANTI_GEOMETRY);
				if (image->bLowQuality)
					bcRender.SetBool(RDATA_RENDERENGINE, RDATA_RENDERENGINE_PREVIEWSOFTWARE);
				image->pDest->Clear(0, 0, 0);
				image->lResult = RenderDocument(image->pDoc, bcRender, nullptr, nullptr, image->pDest,
													 RENDERFLAGS_EXTERNAL | RENDERFLAGS_PREVIEWRENDER, image->pThread);
			}
			return true;
			break;
		}

last line in the code explains why I must know how to fill this Bitmap!!

Helper

On 21/01/2015 at 11:30, xxxxxxxx wrote:

Hi MohamedSakr,

Sorry, but I still don't understand what you need to know about 'how the bitmap is filled'. You're going to have to be more precise. Perhaps it would be best if you told me what is the context of the problem and the solution you're seeking? You previously stated you know how the bitmap methods work from "vpvisualizenormals" example in the SDK, so I guess you undertand how to draw into a bitmap?

I also have no idea what you mean by "last line in the code explains why I must know how to fill this Bitmap!!" What's wrong with the last line? I figure you're asking about RenderDocument(), for which I see no issue when running the MaterialData plugin in C4D, so I figure you're not reporting a defect.

Joey Gaspe
SDK Support Engineer

Helper

On 21/01/2015 at 12:43, xxxxxxxx wrote:

Hi Joey,

well it is not a defect Tongue , it is just about the Bitmap itself, "image->pDest" in the above code, from vpvisualizenormals I can override the color channel, is this the Bitmap which is passed here? in vpvisualizenormals.cpp example, in the Execute function, there is this line of code

VPBuffer* rgba = vps->render->GetBuffer(VPBUFFER_RGBA, NOTOK);

and it gets the data from this buffer, with GetLine() , overrides it with SetLine().
the question is: is this buffer "VPBUFFER_RGBA" == the passed Bitmap "image->pDest"?? why I ask?
because this is the only buffer that I can fill from the SDK examples, if they are not the same, then how can I fill the Bitmap to VIEW the result in the Material Preview window?

Note: I changed the font to be uniform (Arial) to make the post easier to read. JG

Helper

On 22/01/2015 at 08:22, xxxxxxxx wrote:

Hi MohamedSakr,

Thank you for the clarifications! The answer is yes, the bitmap passed as "image->pDest" to RenderDocument() becomes the internal render bitmap of type MultipassBitmap. When you call "vps->render->GetBuffer(VPBUFFER_RGBA, NOTOK)", you get the renderer's MultipassBitmap pointer. As stated in the documentation, a VPBuffer is represents the same class internally as a MultipassBitmap, so a VPBuffer can be cast to the latter, and vice versa. Therefore, you should be able to fill the bitmap to view the results in the material preview window.

Joey Gaspe
SDK Support Engineer

Helper

On 22/01/2015 at 10:15, xxxxxxxx wrote:

Hi Joey,

thanks a lot for clarification Tongue , I will test it now, you made my day.