Rendering sans RENDERFLAG_EXTERNAL

Helper

THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED

On 07/10/2004 at 20:15, xxxxxxxx wrote:

User Information:
Cinema 4D Version:   8.503+
Platform:   Windows ;   Mac OSX ;
Language(s) :     C++ ;

---------
When using RenderDocument is there any way without using RENDERFLAG_EXTERNAL to:

a) Have the progresshook update and be sent the actual progress of the render and...
b) Modify the resolution settings/aspect ratio of the render?

Helper

THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED

On 08/10/2004 at 09:43, xxxxxxxx wrote:

Well, for future interest the answer to part (a) is a simple hack as follows:

Make a struct like this:

  
struct ProgressData {  
LONG count; //iterator  
Real height; //real to save conversion time  
};

then where you're going to do your render:

  
ProgressData mydata;  
  
mydata.height=mybmp->GetBh();  
mydata.count=0;  
  
if (RenderDocument(mydoc,myrendersettings,myprogresshook,&mydata;,mybmp,RENDERFLAG_PREVIEWRENDER | RENDERFLAG_NODOCUMENTCLONE, mythread)!=RAY_OK) return FALSE;

then in your progresshook just do the following

  
//-------------------------------  
//ignore p as it's not filled without RENDERFLAG_EXTERNAL!!!  
void myprogresshook(Real p,void* pd) {  
ProgressData *mydata=(ProgressData* )pd;  
mydata->count++;  
StatusSetBar(floor((mydata->count/mydata->height)*100.0));  
}

Now i guess i'll have to look into working out how to exactly get the bitmap the right shape/size and camera offset right to compensate for the aspect ratio problems whilst retaining the resolution for the section that needs to be rendered correctly. Currently if I touch camera offset, even setting it to 0.0 it seems modify the camera in quite unexpected and undesirous ways

Helper

THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED

On 08/10/2004 at 23:35, xxxxxxxx wrote:

oh and just to follow up on the second after playing around for a while i finally found that the offset has no relation to the cameras actual offset values as any logic might normally follow, but is just another way to say setpos, or setmg or even setorigin... gah... perhaps this is some throwback to a point when camera objects were not accesible as normal objects and needed their own routines to set their matrices/psr (if so where's the s & r bits?). so this means setting the film offset value has to be done using get/setparameter for anyone interested *doh*.

in the end this wasn't necesary as it happens, a simple modification of the full bitmaps size being used to compensate for the aspect ratio in combination with a cutting down of the specific area of the bitmap rendered was sufficient for my needs and hopefully should not give too great a memory overhead for this small but important section.