Is anyone aware of a filter existing in the Croquet code (like the
wire frame window that could be brought up in Cobalt) that can be applied - but in this case a red/cyan anaglyph filter (as opposed to the wireframe filter/window). Best Regards, - Rich -- |
Rich: Yes -- but it was deployed in Jasmine Croquet. I'll find it and
give you a link to download. It worked so beautifully -- and I demonstrated it at C5 in 2006. I would love for it to be ported to Cobalt. (and would do it myself if I had the opportunity). -- Ed Rich White wrote: > Is anyone aware of a filter existing in the Croquet code (like the > wire frame window that could be brought up in Cobalt) that can be > applied - but in this case a red/cyan anaglyph filter (as opposed to > the wireframe filter/window). > > Best Regards, > - Rich > -- > |
Ed,
Did you get a chance to post the anaglyph filter code link? - Darius ___ On Fri, Jan 22, 2010 at 8:34 AM, Ed Boyce <[hidden email]> wrote: Rich: Yes -- but it was deployed in Jasmine Croquet. I'll find it and |
In reply to this post by RichWhite
Hello,
I have just uploaded the experimental anaglyph TStereoFilter into Cobalt contributions repository. It is based on the work of Daniel Faken (ChemStereo for Croquet Jasmine). Best regards, Nikolay On Fri, Jan 22, 2010 at 6:07 PM, Rich White <[hidden email]> wrote: Is anyone aware of a filter existing in the Croquet code (like the stereoFilter.jpg (50K) Download Attachment |
Great! And thank you for this Nikolay. It'll be in the next build.
Cheers, -- John
On Wed, Apr 14, 2010 at 01:59, Nikolay Suslov <[hidden email]> wrote: Hello, -- John Dougan [hidden email] |
John,
Yes, it would be great. Thinking that this feature will give an interesting immersion experience to anyone who will work with Cobalt modeling tools especially, like editing mode, painting in 3D, CAD etc., and have an ability to interact with virtual world in stereo mode, conformable to the human perception of reality. Thanks, Nikolay On Thu, Apr 15, 2010 at 3:30 AM, John Dougan <[hidden email]> wrote: Great! And thank you for this Nikolay. It'll be in the next build. |
I'm getting this error when I use this function and other glMultiTex
functions. Other EXT and ARB functions work fine. What could be wrong ? It stems from OGLWin32(Object)>>externalCallFailed The card is a recent NVidia card, OpenGL is all working fine (e.g. Cobalt runs), and the same code runs fine on my ATI card. |
Hehe,
i am planning to do it right with my NB->OpenGL bindings. It fails , because all extension function pointer on windoze, should be fetched using wglGetProcAddress at already created , and selected rendering context. See: http://www.opengl.org/resources/code/samples/sig99/advanced99/notes/node396.html On 16 May 2010 13:00, Matthew Chadwick <[hidden email]> wrote: > I'm getting this error when I use this function and other glMultiTex > functions. Other EXT and ARB functions work fine. What could be wrong ? > > It stems from OGLWin32(Object)>>externalCallFailed > > The card is a recent NVidia card, OpenGL is all working fine (e.g. Cobalt > runs), and the same code runs fine on my ATI card. > -- Best regards, Igor Stasenko AKA sig. |
Hi Igor,
you should take a closer look at Croquet's FFI bindings. All the function addresses *are* replaced upon context creation. Otherwise this wouldn't work at all. - Bert - Am 16.05.2010 um 04:06 schrieb Igor Stasenko: > > Hehe, > i am planning to do it right with my NB->OpenGL bindings. > > It fails , because all extension function pointer on windoze, should > be fetched using > wglGetProcAddress at already created , and selected rendering context. > See: > http://www.opengl.org/resources/code/samples/sig99/advanced99/notes/node396.html > > On 16 May 2010 13:00, Matthew Chadwick <[hidden email]> wrote: >> I'm getting this error when I use this function and other glMultiTex >> functions. Other EXT and ARB functions work fine. What could be wrong ? >> >> It stems from OGLWin32(Object)>>externalCallFailed >> >> The card is a recent NVidia card, OpenGL is all working fine (e.g. Cobalt >> runs), and the same code runs fine on my ATI card. >> > > > > -- > Best regards, > Igor Stasenko AKA sig. |
On 16 May 2010 20:16, Bert Freudenberg <[hidden email]> wrote:
> Hi Igor, > > you should take a closer look at Croquet's FFI bindings. All the function addresses *are* replaced upon context creation. Otherwise this wouldn't work at all. > I dimly remember how its done. The other thing is, that depending on a chosen context's pixel format it may or may not support an extension. > - Bert - > > Am 16.05.2010 um 04:06 schrieb Igor Stasenko: >> >> Hehe, >> i am planning to do it right with my NB->OpenGL bindings. >> >> It fails , because all extension function pointer on windoze, should >> be fetched using >> wglGetProcAddress at already created , and selected rendering context. >> See: >> http://www.opengl.org/resources/code/samples/sig99/advanced99/notes/node396.html >> >> On 16 May 2010 13:00, Matthew Chadwick <[hidden email]> wrote: >>> I'm getting this error when I use this function and other glMultiTex >>> functions. Other EXT and ARB functions work fine. What could be wrong ? >>> >>> It stems from OGLWin32(Object)>>externalCallFailed >>> >>> The card is a recent NVidia card, OpenGL is all working fine (e.g. Cobalt >>> runs), and the same code runs fine on my ATI card. >>> >> >> >> >> -- >> Best regards, >> Igor Stasenko AKA sig. > > > > -- Best regards, Igor Stasenko AKA sig. |
Free forum by Nabble | Edit this page |