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

Z-buffer range should be set in a more sensible manner #73

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

Comments

@GoogleCodeExporter
Copy link

Currently the range of the z buffer is set according to its bit depth. (def 
ortho in cameras.py)

This is however not their correct use. In order for these parameters to be 
meaningful, they have to be set in accordance with the dimensions of the scene.

For instance, I am currently rendering a lot of small objects (0.01 units in 
diameter). They suffer horrible z-fighting problems with these hardcoded 
z-limits.

Even as defaults, this setting is not particularly sensible, but in the end, 
youd want to either estimate these values from the extents of the scene 
automatically (hard, since it is not a very general problem), or give the 
end-user a parameter to give reasonable context dependent guesses. (which is a 
lot simpler to implement)

Ive hardcoded my own camera limits in for now. 

Thanks again for the excellent piece of software!

Original issue reported on code.google.com by [email protected] on 18 May 2013 at 6:57

@GoogleCodeExporter
Copy link
Author

The current Z-buffer range is hardcoded to offer good results in the range of 
0.1 - 1000 or so. The Axes actually does have a sense of its size, so I guess 
it should be possible to set the Z-buffer range accordingly. Allowing the user 
to override the default behavior would be helpful too.

Original comment by [email protected] on 19 May 2013 at 1:57

  • Changed title: Z-buffer range should be set in a more sensible manner
  • Changed state: Accepted

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