[Solved] Equirectangular progressive render not accumulating subframes?

[3dickulus]

I've just been fiddling around with the equirectangular projection and I noticed that it doesn't accumulate renders ie:it renders the subframes all the same so the image never gets better no matter how many subframes.

in the Examples/Include/3D.frag file I see at line 164...

Code:

	vec2 jitteredCoord = coord + AntiAliasScale*PixelScale*FOV*disc;
	
	// Direction from Lens positon to point on FocalPlane
	vec3 lensOffset =  r.x*Right + r.y*UpOrtho;
	vec3 rayDir =  (Dir+ jitteredCoord.x*Right+jitteredCoord.y*UpOrtho)*FocalPlane-(lensOffset);
	rayDir = normalize(rayDir);

	if (EquiRectangular) {
		rayDir = equiRectangularDirection(viewCoord2, Dir, UpOrtho, Right); 
	} 

"Dir" does not get the jitteredCoord in the equirectangular call for the accumulating progressive render, however if you use the previously calculated method for Dir in the equirectangular call like this...

Code:

	if (EquiRectangular) {
		rayDir = equiRectangularDirection(viewCoord2, (Dir+ jitteredCoord.x*Right+jitteredCoord.y*UpOrtho), UpOrtho, Right); 
	} 

or this...

Code:

	if (EquiRectangular) {
		rayDir = equiRectangularDirection(viewCoord2, rayDir, UpOrtho, Right); 
	} 

then the progressive render works as expected.

can anyone verify this or let me know if my assumptions about the math is in error?

[barcud]

Not sure I am doing the right thing here 
I changed 3D.frag to the second version

Code:

rayDir = equiRectangularDirection(viewCoord2, rayDir, UpOrtho, Right);

and did a build of my Flythrough frag but that did not produce an proper image.

Then I changed 3D.frag to version one

Code:

rayDir = equiRectangularDirection(viewCoord2, (Dir+ jitteredCoord.x*Right+jitteredCoord.y*UpOrtho), UpOrtho, Right);

which creates an image close to the original one but it is somehow not properly equirectangular (left side and right side does not match up properly).

Not sure that is what I was supposed to test.
The image below has the view 'back' - where the right hand side and left hand side of the equirectangular image should match up to create a full sphere.

[3dickulus]

Thanks for the infos, it helps a bit to know what it's doing on other machines.
You don't have to do anything, I would suggest staying with the original version of 3D.Frag until this gets fixed as it gives you the correct projection and does what you want.

I just noticed that progressive rendering is effectively disabled when rendering in equirectangular mode, that means the image will never get any better as in non-equirectangular mode where more subframes = better image quality.

Re:projection Because FOV and Focalplane are used in the calculation of the direction vector they must be adjusted to nonZero values, Focalplane to 1.0 and the FOV needs to be something other than zero too, a very small number minimizes the distortion but also minimizes the accumulative effect of progressive rendering  the math used up to this point relies on FOV being something(anything) in order to "jitter" the rendering for progressive accumulated frames.

I've posted the topic so that, hopefully, someone with a larger math-brain than mine will be able to offer a solution that works without distorting the image out of sphere.

[3dickulus]

this appears to work...  

modified fragment main() in Examples/Includes/3D.frag

Code:

void main() {
	init();

	// A Thin Lens camera model with Depth-Of-Field
	// We want to sample a circular diaphragm
	// Notice: this is not sampled with uniform density
	vec2 r = Aperture*uniformDisc(viewCoord*(float(subframe)+1.0));
	vec2 disc; // subsample jitter
	vec2 jitteredCoord;
	// Direction from Lens positon to point on FocalPlane
	vec3 lensOffset = r.x*Right + r.y*UpOrtho;
        vec3 rayDir;
	// Direction from Lens positon to point on FocalPlane

	if (EquiRectangular) {
	  disc = uniformDisc(float(1+subframe)); // subsample jitter
	  jitteredCoord = AntiAliasScale*PixelScale*disc;
	}
	else {
	  disc = uniformDisc(coord*float(1+subframe)); // subsample jitter
	  jitteredCoord = coord + AntiAliasScale*PixelScale*FOV*disc;
	}

	//vec3 rayDir = normalize (Dir+ jitteredCoord.x*Right+jitteredCoord.y*UpOrtho)*FocalPlane-(lensOffset);
	rayDir = (Dir+ jitteredCoord.x*Right+jitteredCoord.y*UpOrtho)*FocalPlane-(lensOffset);
	rayDir = normalize(rayDir);

	if (EquiRectangular) {
	  rayDir = equiRectangularDirection(viewCoord2, rayDir, UpOrtho, Right);
	}

	vec3 c =  color(from+lensOffset,rayDir);

	// Accumulate
	vec4 prev = texture2D(backbuffer,(viewCoord+vec2(1.0))*0.5);
	float w =1.0-length(disc);
	if (GaussianWeight>0.) {
		w = exp(-dot(disc,disc)/GaussianWeight)-exp(-1./GaussianWeight);
	}

	gl_FragColor =(prev+ vec4(c*w, w));
}

Edit: in the above code the calls to uniformDisc() are throwing a casting warning...

Code:

uniformDisc(viewCoord*(float(subframe)+1.0))
uniformDisc(float(1+subframe))
uniformDisc(coord*float(1+subframe))

need to look like...

Code:

uniformDisc(viewCoord*(vec2(subframe+1))
uniformDisc(vec2(subframe+1))
uniformDisc(coord*vec2(subframe+1))

Edit:end

before change and after change rendering 100 subframes...

[SCORPION]

Hmm, I noticed. that sometimes there is no improvement in the image, although the sub-frames are accumulated. I do not know. what is the reason. Just does not work.
This is a modified file 3D.frag But strange - if you save a project fragmentarium restart and open the project again - all starts.

[3dickulus]

Each project, "<name>.png Files", will contain the frag files it used when it was created,
so if you have edited the Examples/Include/3D.frag file it will only show up in new projects,

1) delete the other frag files in an old project folder keeping <name>.frag
2) move <name>.frag into a folder without the extra files

it will look for what it needs in Examples/Include folder and find the version of 3D.frag you changed.

hope that helps

[SCORPION]

No, I completely replaced the file 3D. frag the road Examples - Include in the edited. The original file is stored in another location just in case.
Another problem also happens - when to switch to the tab animation, and then a progressive - subframes do not even work.

[3dickulus]

you may have to hit "Build" when switching tabs, seems to work ok here...

did you compile from source or use precompiled binary exe ?

[SCORPION]

No, I used to build ready Windows. Compile from source, I can not (((((Actually, I have this annoying problem. Always possible to save the project and restart fragmentarium - then it starts to work fine. Question, of course, is why in the course of work suddenly stopped working subframes?

[3dickulus]

I have had some problems with the win exe not rendering paths even after commenting out other GL rendering commands so that the only thing to render is the paths,
works fine for linux/bsd rendering only paths but not in win exe

I don't like to provide compiled binaries as one has no idea what might be inside, compile from source if you can, that way you get a binary that is specifically optimized for your CPU and linked against your gfx card driver and GL dlls.

[3dickulus]

I can't seem to replicate the problem but this quote from Syntopia might help... http://www.fractalforums.com/index.php?topic=13388.msg51925#msg51925

Whenever you enable dual-buffering, by using something like:

Code:

#buffer RGBA32F
#buffershader "BufferShader.frag"

Fragmentarium will create two buffers, with the requested datatype (32-bit floats for each of the 4 color channels - from now I will call these 'HDR' buffers - in the example above).

When the shader is executed, it will write to the front-buffer, but it is allowed to sample from the backbuffer.
After it has rendered a frame, the backbuffer and frontbuffer is swapped - so the backbuffer always contains the previous output from the main shader.
The 'BufferShader.frag' is different. It reads from the frontbuffer, and is responsible for rendering the HDR buffer to the screen, which is always 8-bit RGBA. Typically it will contain code for tonemapping and post-processing the HDR buffers. The buffershader is not required - if is omitted colors will simply output whatever is in the HDR buffers, clamped from 0 to 1.

what you describe sounds like a buffer is getting dropped and switching to non-progressive single buffer.

If I can replicate it I will try to fix it.

[SCORPION]

Yeah, I guess that's what happens. But for me it's not a problem! If it did not work at all - would then be a problem.

I can not do a compilation, I do not know anything about programming, so I'll be ready to work with assemblies. .exe for Windows.

[3dickulus]

also when you "Play" animation to the end it stops by turning off "Play", if it has stopped and you switch from Animation to Progressive you need to hit "Play" to turn on Progressive again.

[SCORPION]

Yes, I found this way! But sometimes it also stops working!
Well, for me the problem is now in a very strong way of smoothing splines. But it is necessary to discuss in your theme splines.