Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Big changes to how visvis renders the scene #41

Closed
GoogleCodeExporter opened this issue Sep 1, 2015 · 1 comment
Closed

Big changes to how visvis renders the scene #41

GoogleCodeExporter opened this issue Sep 1, 2015 · 1 comment

Comments

@GoogleCodeExporter
Copy link

I'm considering making some big changes to how visvis renders stuff.

I'm searching for an approach that enables:
  - anti aliasing of any object (lines, meshes, etc.) (full screen anti-aliasing)
  - making screenshots at a higher resolution than screen resolution
  - proper handling of transparency in a generic manner
  - beautiful text
  - preferably allows off line rendering
  - preferably allows objects to render at a lower screen resolution (e.g. faster 3D volume rendering during user interaction)

Two base techniques
-------------------

I've played with two techniques that can serve as a basis for this. The first 
is using the accumulation buffer. Basically, you render the same scene multiple 
times with small offsets in screen resolution (i.e. jitter), and you average 
the result. I got a proof of concept working and the result looks very nice. 
Although it's pretty straight forward, it does seem a bit jerky, probably 
because the whole overhead of the visivis render pipeline is executed multiple 
times.

The second approach uses frame buffer objects (FBO) to render to a texture 
instead of the default frame buffer. You can make this buffer any size you 
want. To do anti-aliasing you simply render the screen at a higher resolution 
and then draw the resulting texture to the screen while averaging the 
"sub-pixels" (in a fragment shader). This approach offers many niceties such as 
high res screenshots, and has the significant advantage that you only have to 
execute the visvis pipeline once.

FBO's are available on many systems as an extension, and are part of the core 
of openGl in 3.0. For systems that do not have FBO's available we can either 
use the accumulation buffer approach, or disable some features.

Transparency
------------

Transparency is hard. To do it right you have to draw the objects in the right 
order, or use approximations to avoid that. In any case you must draw all 
opaque objects first. Two interesting approaches for alpha blending are 
described in 
http://developer.download.nvidia.com/SDK/10/opengl/src/dual_depth_peeling/doc/Du
alDepthPeeling.pdf
One is easy and fast but makes approximations, the other seems harder to 
implement and is slower but provides correct results.

Interestingly, the FBO approach allows us to render each object to a texture 
and then combine these resulting textures using either alpha compositing 
technique. We would thus have a method to deal with transparency in a uniform 
way. (this technique would be per-object though, it would not blend different 
parts of the same mesh).

Text
----

Either approach would make it pretty straightforward to display nice text; we 
simply render the un-anti-aliased text at the higher resolution, and the full 
screen anti-aliasing will make it look nice. 

I tested that this works using text rendered by Qt. The text suffers from the 
standard glitches that anti-aliased text has, such as a bit blurry appearance. 
But rotating text etc. requires nothing special. The FBO approach would 
probably allow rendering text separately on a screen-size texture, using 
sub-pixel positioning to create that ultra-crisp fonts Robert demonstrated in 
issue 25.


Original issue reported on code.google.com by almar.klein@gmail.com on 20 Jun 2012 at 12:48

@almarklein
Copy link
Owner

These changes are one of the motivations for the Vispy project. They would mean a major rework of Visvis and I am not going to do that.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants