I am currently using shadow volume for my game (zfail).
While digging online I found some posts that mention that the method is patented, is that true? Does that mean I cannot use stencil shadows?
Please advise,
Tks
How can somebody paitent the use of an Open API and be taken seriously?
That’s like writeing some lines of code as soon as a new version of OpenGL is released and immediately making a patient on that code. Ridiculous.
…hang on, that’s a good way to make some money!
Hehe, nevertheless it has been done, the only thing that I can’t figure out is what exactly they patent. I read the paper but cannot determine exactly if they patent a 2 pass or 1 pass using double-sided stencil buffer?
What Im using is Zfail using 1 pass using EXT_stencil_two_side and
EXT_stencil_wrap (like on http://www.paulsprojects.net/opengl/shadvol/shadvol.html), dunno if that can be the workaround that would determine that basically its not the same thing as what they patent.
Anybody that can enlighten me on the subject would be tremendously helpful.
John Carmack is currently busy rewriting its own implementation for the Doom3 open source code release :
http://twitter.com/#!/ID_AA_Carmack/status/136614459887202305
http://twitter.com/#!/ID_AA_Carmack/status/137189212519792640
Not sure when the release will happen but you will be able to check how he worked around the ‘Creative’ patent.
While digging around I found that the EXT_stencil_two_side method does not seems to cause issues with the patent.
However, now Im stuck with another problem. Im using GLES and I cannot seems to find a way to clamp the vertices that I extrude using light direction to the near and far plane.
It seems that GL_ARB_depth_clamp is what Im looking for but it is not available in GLES. Does anybody know another way to clamp the vertices?
tks!
Well, from back when I looked into shadow volumes, the other main solution for “Depth Fail’s” far clipping problem is to push the far clip out to infinity. There’s a special projection matrix for that. See Efficient Shadow Volume Rendering in GPU Gems 1.
Also (re emulating depth clamp) I’d seen mention before of shader methods of emulating NV_depth_clamp/ARB_depth_clamp but haven’t looked into them. Here are a few links from a quick google:
The fact that you mentioned “near” here concerns me a little. Depth clamp doesn’t work well for that, and you wouldn’t use depth clamp to clamp near with shadow volumes AFAIK.
Near plane depth clamping may be necessary to implement a certain form of ZPass shadow volumes, but it is not needed for ZFail. There , only the far clip plane is of concern and the easiest way to work around it is by using a projection matrix that has an infinitely far clip plane as mentioned by Dark Photon.
Any self-respecting programmer should ignore software patents. It is virtually impossible to write even a modest “hello world” progam without violating someone’s patent. The only solution to protect oneself is civil disobedience; to violate these patents.
Historically speaking, any extensions exposed to OpenGL means you can freely use the feature, because you as programmer are an end-user. Vendors such as nVidia, ATI/AMD and Intel have exchanged licences for patented tech to allow each other to expose it in their drivers/hardware. See it as a form of Mutually Assured Destruction. If one vendor would impose such restriction on another’s customers, other vendor(s) might revoke licences. It’s a minefield, so every all parties play safe.
In the case of Carmack’s reverse, it’s a classical case of abusing the patent system for extortion. Creative Labs was never a big player in the graphics hardware business, I’m pretty sure they never manufactured any hardware close to capable of implementing their own patent.
It is virtually impossible to write even a modest “hello world” progam without violating someone’s patent.
And yet, you don’t see people getting sued over patent infringement for stuff like that. By your logic, every program written in the last 10 years is suit-worthy. Yet, most of them haven’t been sued. Big ones, like Microsoft Office or Windows; little ones like LibreOffice, etc.
Maybe you’re just blowing the threat out of proportion.
The only solution to protect oneself is civil disobedience.
Civil disobedience generally requires having fines and such imposed on you. That’s fine if you’re the only one affected, but patent suits can destroy entire companies.
Taking that kind of chance is just irresponsible. The solution that allows companies to continue to function is simply doing diligence. Buying software from reputable sources. Etc.
The big ones haven’t been sued? Have you been living under a rock? You know very well this is actually happening right now, it just doesn’t involve graphics software patents at the moment. Courts are swamped with these sort of lawsuits all the time, and they are making headlines.
Maybe you’re just blowing the threat out of proportion.
Maybe. But that’s the whole problem. Can you say with 100% certainty that your software doesn’t infringe on any patents? Even a lawyer cannot give you that guarantee. This is why software patents are moot.
Civil disobedience generally requires having fines and such imposed on you. That’s fine if you’re the only one affected, but patent suits can destroy entire companies.
That is true, but what is the alternative? Actively seek out patent holders and pay protection money? How can you be sure your software infringes any given patent? How much does it cost you to do all of this work? I’m pretty sure this quickly becomes unprofitable.
Taking that kind of chance is just irresponsible. The solution that allows companies to continue to function is simply doing diligence. Buying software from reputable sources. Etc.
What is considered a ‘reputable source’ when even the ‘big ones’ are perpetually embroiled in patent lawsuits?
Anyway you look at it, software patents are a lose-lose situation for anyone but lawyers and patent trolls.
Ok, I’ll defer to your experience here. Intuitively though, near clamping with ZPass (Depth Pass) seems problematic because it should only work reliably for fragments which land in the frustum formed by the eye and the corners of the near clip plane. Anything else (points behind the eye, etc.) should be clipped away by LRBT planes, preventing you from getting reliable shadow volume clamping for all points on the eye’s side of the near clip plane.
…thus the need for Depth Fail (or manual near cap generation).
Assuming I’m not confusing things here…in my shadow mapping implementation, I saw exactly that. Depth clamping is just that; clamping, it doesn’t prevent clipping if you think of it. Anything behind the eye position is in practice still clipped away, otherwise you’d get really weird inverse projection for perspective frustums. Of course for orthographic projections this is not a problem.