Thoughts on Velocity Information

[RotemS]

I spoke too soon actually. This seems to only work when filtering is disabled for the element (when we only use the 'front' Fragment in storeSample).
Anyways it's a compromise I can gladly live with.

[vlado]

There's probably a way to resolve this; let me know if you need a solution at some point.

Best regards,
Vlado

[RotemS]

Thanks. For now it looks like this will work.

Another question: Are 'geometry samples' guaranteed to be equally distributed temporally?
In other words, with the following settings:

Duration (frames): 2.0
Interval center: 0.0
Geometry samples: 3

Are the 3 samples guaranteed to be at (T-1), (T), (T+1) ?

[vlado]

Are 'geometry samples' guaranteed to be equally distributed temporally?

Yes.

Best regards,
Vlado

[RotemS]

Just to update, this has worked very well for my purpose.
The only issue I'm still battling with is if the user is rendering via a VRayPhysicalCamera.
Do you know a way I could enforce a duration of 2.0 frames and an interval center of 0.0 at rendertime regardless of the camera settings, or more simply to tell VRay to treat the camera as if it were a regular camera and use the regular motion blur?

[RotemS]

Another problem I'm currently facing is that I'm getting severe artifacts when the objects are far from the origin. I get the "Scene is too far away from origin, possible raycast errors" warning.
The RGB element is fine for the same render.

Is there anything that can be done about this on my side?
If not, could anything be done about this on your side?

[vlado]

There's an "occlusion bias" parameter in the VRaySamplerInfo render element, maybe try increasing or decreasing it a little bit.

Best regards,
Vlado

[RotemS]

Thank you for your response.
The artifacts are actually in the X/Y (R/G) coordinates, not the occlusion data. I'm actually not using occlusion, instead using the B channel for scene-space Z velocity.

This is the code I'm using to compute the data (modified from original VRaySamplerInfoTex code):

DefaultVRayShadeInstance *si = (DefaultVRayShadeInstance*)GET_INTERFACE(rc.rayresult.si, EXT_DEFAULT_SHADE_INSTANCE);
if (si)
{
	// Get the point at the start of the motion blur interval
	Vector offsetPt = si->getBasePt(rc, (which == timeMoment_frameEnd) ? 
		DefaultVRayShadeInstance::baseTime_frameEnd : 
		DefaultVRayShadeInstance::baseTime_frameStart);

	// Project the point onto the camera at the start of the motion blur interval
	const VRaySequenceData &sdata = rc.vray->getSequenceData();
	double time = (which == timeMoment_frameEnd) ? 1.0 : 0.0;
	TracePoint offsetPtCam = sdata.cameraImageSampler->interpolateTimePointInverse(TracePoint(offsetPt), time);

	//calculate the screen-space offsets
	VR::Vector2 offset_p_img, this_p_img;
	if (sdata.cameraRaySampler->mapToScreen(offsetPtCam, offset_p_img, time) &&
	    sdata.cameraRaySampler->mapToScreen(rc.rayresult.getPoint(), this_p_img, 0.5))
	{
		double depthDelta = (offsetPt - rc.rayparams.tracedRay.p).length() - rc.rayresult.wpointCoeff;
		return Vector(
			(double)offset_p_img.x - (double)this_p_img.x,
			(double)offset_p_img.y - (double)this_p_img.y,
			-depthDelta);
	}
}
return Vector(0.0f, 0.0f, 0.0f);

From my tests I've verified that the integrity of the data is good up until the calls to mapToScreen. It is there that the values get a sort of gentle diamond pattern.
Attached is a render of the result of offset_p_img.x, after contrast and exposure applied to show the pattern.



Since the diamond pattern artifacts of the two points are not aligned, we get more severe and noticeable artifacts when subtracting one point from the other.

So.. the question is: is there anyway to have mapToScreen use a higher level of precision than it does by default, or can another method be used to map to screen space?

[vlado]

Ok, I see. Do you think you can get me a repro scene to play with?

Best regards,
Vlado

[RotemS]

Ok, I see. Do you think you can get me a repro scene to play with?

Absolutely, attached here. The file is saved using Max2014 and VRay 3.30.04.

There are two cameras, one near the origin and one very far away. Rendering frame 5 of the animation results in good.jpg and bad.jpg respectively in the VraySamplerInfo element.

Thanks for taking a look.

[RotemS]

Hi. Any news on this issue?
I realize it's not the most widely used feature, but already a considerable part of our projects use a workflow which includes it, and fixing it would save us a lot of trouble offsetting complete scenes closer to the origin.

[vlado]

I'm still thinking how best to work around this; in a fit of stupidity I've made mapToScreen() take a single precision Vector rather than the double-precision TracePoint that comes in from the ray context, and changing it directly would break the SDK.

I hope to have a solution for you in the next few days.

Best regards,
Vlado

[RotemS]

Thanks for looking into it, much appreciated.

If it works for you, I could happily live with something like an overload of mapToScreen() which takes doubles.

[RotemS]

Sorry to be a pest, but any news on this? It would mean a lot to our workflow if it could be included in the upcoming service pack.

[vlado]

For the nightly builds on Monday, you should be able to use the following code:

TracePoint pt=...;
if (sdata.cameraRaySampler->getDoDOF() & VR::vrayCameraFlags_canDoFrustrum) {
  Vector2 screenPt;
  int valid=static_cast<VRayCamera3*>(sdata.cameraRaySampler)->mapTracePointToScreen(pt, screenPt, rayTime, dof_uc, dof_vc);
  if (valid) {
    ...
  }
}

I hope this helps.

Best regards,
Vlado