|
From: James W. <ja...@fr...> - 2007-05-30 19:50:22
|
Description The Quesa OpenGL renderer now has an option to render shadows. It produces sharp-edged shadows from any directional, spot, or point light that has its cast-shadows flag set to kQ3True. It respects the casts-shadows style but not the receive-shadows style. Translucent objects do not cast shadows, nor do lines or points. Rendering with shadows can be requested by setting an object property on the renderer object: TQ3Boolean theFlag = kQ3True; Q3Object_SetProperty( theRenderer, kQ3RendererPropertyShadows, sizeof(theFlag), &theFlag ); This option can be used with or without the per-pixel lighting option. It is not intended to work with orthographic cameras. Hardware Requirements In order to render with shadows, your OpenGL drawing context must: 1. Be able to have a stencil buffer at least 8 bits deep, as well as a depth buffer. (This is usually not a problem. One case where it fails is the Windows software renderer.) 2. Support either OpenGL 2.0 or the GL_EXT_stencil_two_side extension. It is preferable, but not essential, to have the extensions GL_EXT_stencil_wrap and GL_NV_depth_clamp as well. Warnings The algorithm sets the "yon" value of your camera range to infinity. To prevent surprises, it would be a good idea to set "yon" to infinity yourself. While it is true that you get the best depth resolution when hither is as large as possible and yon is as small as possible, it is much more important to make hither as large as possible. If you are using Quesa on Windows, beware that Windows does not allow setting the pixel format of a window more than once. This means that if you start rendering without shadows, and then attempt to turn on shadows, it will fail, because you will not be able to get a stencil buffer. You can work around this problem by explicitly requesting a stencil buffer from the start, using kQ3DrawContextPropertyGLStencilBufferDepth. Performance Shadows require a multi-pass rendering algorithm. The first pass handles ambient light and non-shadow-casting lights, assuming there are no more than 8 of them. Then for each shadow-casting light, there is a stencil marking pass followed by a lighting pass. Naturally, this will be slower than a single-pass algorithm. There is even more of a speed hit if you combine per-pixel lighting with shadows, since each lighting pass will be slower. Naturally, you can improve performance by designating some lights and some objects as not casting shadows. It also helps to use the Remove backfacing style when feasible, and to ensure that your TriMeshes supply face normal vectors. |
|
From: Jose' C. <cru...@ce...> - 2007-05-30 21:40:21
|
> Description > > The Quesa OpenGL renderer now has an option to render shadows. It > produces sharp-edged shadows from any directional, spot, or point =20 > light > that has its cast-shadows flag set to kQ3True. It respects the > casts-shadows style but not the receive-shadows style. Translucent > objects do not cast shadows, nor do lines or points. > Great News!!! > It is not intended to work with orthographic cameras. in that case, it fails or just is ignored? > > One case where it fails is the Windows software renderer. So it's not suitable for printing... or there is a way to render on =20 the GPU for printing? > > > Warnings > > The algorithm sets the "yon" value of your camera range to =20 > infinity. To > prevent surprises, it would be a good idea to set "yon" to infinity > yourself. While it is true that you get the best depth resolution when > hither is as large as possible and yon is as small as possible, it is > much more important to make hither as large as possible. doesn't it restore the yon after the loop? so I've to restore it when =20= switching renderers... one of mine works better with an small range... Pax et Bonum # Dott. Jos=E9 Cruanyes Aguilar - C.E. Soft srl # Pzza. Firenze,4 MILANO - XX Settembre 10, CREMONA # 02,3923101 0372,460602 |
|
From: James W. <ja...@fr...> - 2007-05-30 23:15:57
|
Jose' Cruanyes wrote: >> It is not intended to work with orthographic cameras. > > in that case, it fails or just is ignored? To tell the truth, I didn't test it. It probably fails. >> One case where it fails is the Windows software renderer. > > So it's not suitable for printing... or there is a way to render on > the GPU for printing? There is an option I recently added to render offscreen contexts using framebuffer objects, when the GPU supports FBOs. See kQ3DrawContextPropertyAcceleratedOffscreen. I have not yet used that on Windows, so I cannot swear it is bug-free. >> Warnings >> >> The algorithm sets the "yon" value of your camera range to >> infinity. To >> prevent surprises, it would be a good idea to set "yon" to infinity >> yourself. While it is true that you get the best depth resolution when >> hither is as large as possible and yon is as small as possible, it is >> much more important to make hither as large as possible. > > doesn't it restore the yon after the loop? so I've to restore it when > switching renderers... one of mine works better with an small range... OK, I just added code to restore yon at the end of the frame. -- James W. Walker, Innoventive Software LLC <http://www.frameforge3d.com/> |
|
From: Daniele C. <dca...@in...> - 2007-05-31 08:33:56
|
It is very interesting I would like to try it soon. Can I already download it by cvs? If it isn't possible when will be? Thank's Daniele James Walker ha scritto: > Description > > The Quesa OpenGL renderer now has an option to render shadows. It > produces sharp-edged shadows from any directional, spot, or point light > that has its cast-shadows flag set to kQ3True. It respects the > casts-shadows style but not the receive-shadows style. Translucent > objects do not cast shadows, nor do lines or points. > > Rendering with shadows can be requested by setting an object property on > the renderer object: > > TQ3Boolean theFlag = kQ3True; > Q3Object_SetProperty( theRenderer, kQ3RendererPropertyShadows, > sizeof(theFlag), &theFlag ); > > This option can be used with or without the per-pixel lighting option. > It is not intended to work with orthographic cameras. > > > Hardware Requirements > > In order to render with shadows, your OpenGL drawing context must: > > 1. Be able to have a stencil buffer at least 8 bits deep, as well as a > depth buffer. (This is usually not a problem. One case where it fails > is the Windows software renderer.) > > 2. Support either OpenGL 2.0 or the GL_EXT_stencil_two_side extension. > > It is preferable, but not essential, to have the extensions > GL_EXT_stencil_wrap and GL_NV_depth_clamp as well. > > > Warnings > > The algorithm sets the "yon" value of your camera range to infinity. To > prevent surprises, it would be a good idea to set "yon" to infinity > yourself. While it is true that you get the best depth resolution when > hither is as large as possible and yon is as small as possible, it is > much more important to make hither as large as possible. > > If you are using Quesa on Windows, beware that Windows does not allow > setting the pixel format of a window more than once. This means that if > you start rendering without shadows, and then attempt to turn on > shadows, it will fail, because you will not be able to get a stencil > buffer. You can work around this problem by explicitly requesting a > stencil buffer from the start, using > kQ3DrawContextPropertyGLStencilBufferDepth. > > > Performance > > Shadows require a multi-pass rendering algorithm. The first pass > handles ambient light and non-shadow-casting lights, assuming there are > no more than 8 of them. Then for each shadow-casting light, there is a > stencil marking pass followed by a lighting pass. Naturally, this will > be slower than a single-pass algorithm. There is even more of a speed > hit if you combine per-pixel lighting with shadows, since each lighting > pass will be slower. > > Naturally, you can improve performance by designating some lights and > some objects as not casting shadows. It also helps to use the Remove > backfacing style when feasible, and to ensure that your TriMeshes supply > face normal vectors. > > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by DB2 Express > Download DB2 Express C - the FREE version of DB2 express and take > control of your XML. No limits. Just data. Click to get it now. > http://sourceforge.net/powerbar/db2/ > _______________________________________________ > Quesa-develop mailing list > Que...@li... > https://lists.sourceforge.net/lists/listinfo/quesa-develop > > |
|
From: James W. W. <os...@jw...> - 2007-05-31 16:27:37
|
On May 31, 2007, at 1:29 AM, Daniele Cavallini wrote: > It is very interesting I would like to try it soon. Can I already > download it by cvs? Yes. |
|
From: Daniele C. <dca...@in...> - 2007-06-01 10:05:58
|
If compile with mac os x I haven't problem. The new Renderer with shadows seem work well, with windows xp I have some problem. If I try to download with wincvs I don't download all file (For example Folder Hidden Line missing). It is not a big problem because I can use file download into mac os x. When I compile with visual studio 2005 there is an error: 'INFINITY' undeclared identifier. Can you help me? James W. Walker ha scritto: > On May 31, 2007, at 1:29 AM, Daniele Cavallini wrote: > > >> It is very interesting I would like to try it soon. Can I already >> download it by cvs? >> > > Yes. > > ------------------------------------------------------------------------- > This SF.net email is sponsored by DB2 Express > Download DB2 Express C - the FREE version of DB2 express and take > control of your XML. No limits. Just data. Click to get it now. > http://sourceforge.net/powerbar/db2/ > _______________________________________________ > Quesa-develop mailing list > Que...@li... > https://lists.sourceforge.net/lists/listinfo/quesa-develop > > |
|
From: James W. W. <os...@jw...> - 2007-06-01 16:29:14
|
On Jun 1, 2007, at 3:05 AM, Daniele Cavallini wrote: > If compile with mac os x I haven't problem. The new Renderer with > shadows seem work well, with windows xp I have some problem. > If I try to download with wincvs I don't download all file (For > example > Folder Hidden Line missing). > It is not a big problem because I can use file download into mac os x. > When I compile with visual studio 2005 there is an error: 'INFINITY' > undeclared identifier. > Can you help me? It looks like INFINITY is from C99, not C++... is there a C99 compatibility option you can turn on? INFINITY is only used in QOLights.cpp, right? You could try adding this #ifndef INFINITY #define INFINITY std::numeric_limits<float>::infinity() #endif in that file just after the #includes. > > > > > James W. Walker ha scritto: >> On May 31, 2007, at 1:29 AM, Daniele Cavallini wrote: >> >> >>> It is very interesting I would like to try it soon. Can I already >>> download it by cvs? >>> >> >> Yes. >> >> --------------------------------------------------------------------- >> ---- >> This SF.net email is sponsored by DB2 Express >> Download DB2 Express C - the FREE version of DB2 express and take >> control of your XML. No limits. Just data. Click to get it now. >> http://sourceforge.net/powerbar/db2/ >> _______________________________________________ >> Quesa-develop mailing list >> Que...@li... >> https://lists.sourceforge.net/lists/listinfo/quesa-develop >> >> > > ---------------------------------------------------------------------- > --- > This SF.net email is sponsored by DB2 Express > Download DB2 Express C - the FREE version of DB2 express and take > control of your XML. No limits. Just data. Click to get it now. > http://sourceforge.net/powerbar/db2/ > _______________________________________________ > Quesa-develop mailing list > Que...@li... > https://lists.sourceforge.net/lists/listinfo/quesa-develop |
|
From: James W. <ja...@fr...> - 2007-06-01 17:42:06
|
James W. Walker wrote: > It looks like INFINITY is from C99, not C++... is there a C99 > compatibility option you can turn on? > > INFINITY is only used in QOLights.cpp, right? You could try adding this > > #ifndef INFINITY > #define INFINITY std::numeric_limits<float>::infinity() > #endif > > in that file just after the #includes. P.S. I have checked in changes to QOLights.cpp and E3Math.c, replacing INFINITY with std::numeric_limits<float>::infinity() and including <limits>. Let me know if that works for you. -- James W. Walker, Innoventive Software LLC <http://www.frameforge3d.com/> |
|
From: Daniele C. <dca...@in...> - 2007-06-04 07:33:50
|
I have made a breakthrough. Now the compiling is correct but I have a linking error: 1>Linking... 1> Creating library ../../../SDK/Libraries/Windows/Stub/Quesa.lib and object ../../../SDK/Libraries/Windows/Stub/Quesa.exp 1>QOLights.obj : error LNK2019: unresolved external symbol "public: void __thiscall QORenderer::ShadowMarker::MarkShadowOfTriMesh ... 1>QOLights.obj : error LNK2019: unresolved external symbol "public: void __thiscall QORenderer::ShadowMarker::MarkShadowOfTriangle ... James Walker ha scritto: > James W. Walker wrote: > > >> It looks like INFINITY is from C99, not C++... is there a C99 >> compatibility option you can turn on? >> >> INFINITY is only used in QOLights.cpp, right? You could try adding this >> >> #ifndef INFINITY >> #define INFINITY std::numeric_limits<float>::infinity() >> #endif >> >> in that file just after the #includes. >> > > P.S. I have checked in changes to QOLights.cpp and E3Math.c, replacing > INFINITY with std::numeric_limits<float>::infinity() and including > <limits>. Let me know if that works for you. > |
|
From: James W. W. <os...@jw...> - 2007-06-04 16:08:27
|
On Jun 4, 2007, at 12:33 AM, Daniele Cavallini wrote: > I have made a breakthrough. > Now the compiling is correct but I have a linking error: > > 1>Linking... > 1> Creating library ../../../SDK/Libraries/Windows/Stub/Quesa.lib > and > object ../../../SDK/Libraries/Windows/Stub/Quesa.exp > 1>QOLights.obj : error LNK2019: unresolved external symbol "public: > void > __thiscall QORenderer::ShadowMarker::MarkShadowOfTriMesh ... > 1>QOLights.obj : error LNK2019: unresolved external symbol "public: > void > __thiscall QORenderer::ShadowMarker::MarkShadowOfTriangle ... You need to add the new source file QOShadowMarker.cpp to the project. Over the weekend, I made more commits, with another new source, E3Math_Intersect.cpp. |
|
From: Daniele C. <dca...@in...> - 2007-06-05 07:44:11
|
Today I download from cvs quesa source and I try do compile. Now I have 6 unresolved externals: .... ...E3Ray3D_IntersectBoundingBox... ...QORenderer::ShadowMarker::MarkShadowOfTriMesh... ...E3Cone_IntersectBoundingBox... .... James W. Walker ha scritto: > On Jun 4, 2007, at 12:33 AM, Daniele Cavallini wrote: > > >> I have made a breakthrough. >> Now the compiling is correct but I have a linking error: >> >> 1>Linking... >> 1> Creating library ../../../SDK/Libraries/Windows/Stub/Quesa.lib >> and >> object ../../../SDK/Libraries/Windows/Stub/Quesa.exp >> 1>QOLights.obj : error LNK2019: unresolved external symbol "public: >> void >> __thiscall QORenderer::ShadowMarker::MarkShadowOfTriMesh ... >> 1>QOLights.obj : error LNK2019: unresolved external symbol "public: >> void >> __thiscall QORenderer::ShadowMarker::MarkShadowOfTriangle ... >> > > You need to add the new source file QOShadowMarker.cpp to the > project. Over the weekend, I made more commits, with another new > source, E3Math_Intersect.cpp. > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by DB2 Express > Download DB2 Express C - the FREE version of DB2 express and take > control of your XML. No limits. Just data. Click to get it now. > http://sourceforge.net/powerbar/db2/ > _______________________________________________ > Quesa-develop mailing list > Que...@li... > https://lists.sourceforge.net/lists/listinfo/quesa-develop > > |
|
From: James W. W. <os...@jw...> - 2007-06-05 15:31:08
|
On Jun 5, 2007, at 12:43 AM, Daniele Cavallini wrote: > Today I download from cvs quesa source and I try do compile. > Now I have 6 unresolved externals: > .... > ...E3Ray3D_IntersectBoundingBox... > ...QORenderer::ShadowMarker::MarkShadowOfTriMesh... > ...E3Cone_IntersectBoundingBox... > .... Those symbols are in QOShadowMarker.cpp and E3Math_Intersect.cpp. Did you add them to the project, as I said? > > James W. Walker ha scritto: >> On Jun 4, 2007, at 12:33 AM, Daniele Cavallini wrote: >> >> >>> I have made a breakthrough. >>> Now the compiling is correct but I have a linking error: >>> >>> 1>Linking... >>> 1> Creating library ../../../SDK/Libraries/Windows/Stub/Quesa.lib >>> and >>> object ../../../SDK/Libraries/Windows/Stub/Quesa.exp >>> 1>QOLights.obj : error LNK2019: unresolved external symbol "public: >>> void >>> __thiscall QORenderer::ShadowMarker::MarkShadowOfTriMesh ... >>> 1>QOLights.obj : error LNK2019: unresolved external symbol "public: >>> void >>> __thiscall QORenderer::ShadowMarker::MarkShadowOfTriangle ... >>> >> >> You need to add the new source file QOShadowMarker.cpp to the >> project. Over the weekend, I made more commits, with another new >> source, E3Math_Intersect.cpp. >> >> >> --------------------------------------------------------------------- >> ---- >> This SF.net email is sponsored by DB2 Express >> Download DB2 Express C - the FREE version of DB2 express and take >> control of your XML. No limits. Just data. Click to get it now. >> http://sourceforge.net/powerbar/db2/ >> _______________________________________________ >> Quesa-develop mailing list >> Que...@li... >> https://lists.sourceforge.net/lists/listinfo/quesa-develop >> >> > > ---------------------------------------------------------------------- > --- > This SF.net email is sponsored by DB2 Express > Download DB2 Express C - the FREE version of DB2 express and take > control of your XML. No limits. Just data. Click to get it now. > http://sourceforge.net/powerbar/db2/ > _______________________________________________ > Quesa-develop mailing list > Que...@li... > https://lists.sourceforge.net/lists/listinfo/quesa-develop |
|
From: Daniele C. <dca...@in...> - 2007-06-05 16:25:52
|
I Add E3Math_Intersect.cpp ,QOShadowMarker QOCalctrimeshEdges.cpp (Just I change a "not" with "!") Now compiling and linking is correct with visual studio 2005 (debug version). James W. Walker ha scritto: > On Jun 5, 2007, at 12:43 AM, Daniele Cavallini wrote: > > >> Today I download from cvs quesa source and I try do compile. >> Now I have 6 unresolved externals: >> .... >> ...E3Ray3D_IntersectBoundingBox... >> ...QORenderer::ShadowMarker::MarkShadowOfTriMesh... >> ...E3Cone_IntersectBoundingBox... >> .... >> > > Those symbols are in QOShadowMarker.cpp and E3Math_Intersect.cpp. > Did you add them to the project, as I said? > > >> James W. Walker ha scritto: >> >>> On Jun 4, 2007, at 12:33 AM, Daniele Cavallini wrote: >>> >>> >>> >>>> I have made a breakthrough. >>>> Now the compiling is correct but I have a linking error: >>>> >>>> 1>Linking... >>>> 1> Creating library ../../../SDK/Libraries/Windows/Stub/Quesa.lib >>>> and >>>> object ../../../SDK/Libraries/Windows/Stub/Quesa.exp >>>> 1>QOLights.obj : error LNK2019: unresolved external symbol "public: >>>> void >>>> __thiscall QORenderer::ShadowMarker::MarkShadowOfTriMesh ... >>>> 1>QOLights.obj : error LNK2019: unresolved external symbol "public: >>>> void >>>> __thiscall QORenderer::ShadowMarker::MarkShadowOfTriangle ... >>>> >>>> >>> You need to add the new source file QOShadowMarker.cpp to the >>> project. Over the weekend, I made more commits, with another new >>> source, E3Math_Intersect.cpp. >>> >>> >>> --------------------------------------------------------------------- >>> ---- >>> This SF.net email is sponsored by DB2 Express >>> Download DB2 Express C - the FREE version of DB2 express and take >>> control of your XML. No limits. Just data. Click to get it now. >>> http://sourceforge.net/powerbar/db2/ >>> _______________________________________________ >>> Quesa-develop mailing list >>> Que...@li... >>> https://lists.sourceforge.net/lists/listinfo/quesa-develop >>> >>> >>> >> ---------------------------------------------------------------------- >> --- >> This SF.net email is sponsored by DB2 Express >> Download DB2 Express C - the FREE version of DB2 express and take >> control of your XML. No limits. Just data. Click to get it now. >> http://sourceforge.net/powerbar/db2/ >> _______________________________________________ >> Quesa-develop mailing list >> Que...@li... >> https://lists.sourceforge.net/lists/listinfo/quesa-develop >> > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by DB2 Express > Download DB2 Express C - the FREE version of DB2 express and take > control of your XML. No limits. Just data. Click to get it now. > http://sourceforge.net/powerbar/db2/ > _______________________________________________ > Quesa-develop mailing list > Que...@li... > https://lists.sourceforge.net/lists/listinfo/quesa-develop > > |
|
From: James W. <ja...@fr...> - 2007-06-05 18:21:54
|
Daniele Cavallini wrote: > I Add E3Math_Intersect.cpp ,QOShadowMarker QOCalctrimeshEdges.cpp (Just > I change a "not" with "!") > Now compiling and linking is correct with visual studio 2005 (debug > version). I'm glad to hear you got it working. I checked in a change to QOCalcTriMeshEdges.cpp, removing the not. -- James W. Walker, Innoventive Software LLC <http://www.frameforge3d.com/> |
|
From: Daniele C. <dca...@in...> - 2007-06-06 09:23:06
|
Just two small adjust for release Version into Visual studio: - I Add HiddenLine.h into Additional Include Directories (C/C++ General) - I Change name in Output file QD3D.dll into Quesa.dll (linker General) Two question: Do you think It will be possibile work with orthographic cameras into future? Is it possibile for object don't generate shadows? (example handle). How I can to do this? James Walker ha scritto: > Daniele Cavallini wrote: > >> I Add E3Math_Intersect.cpp ,QOShadowMarker QOCalctrimeshEdges.cpp (Just >> I change a "not" with "!") >> Now compiling and linking is correct with visual studio 2005 (debug >> version). >> > > I'm glad to hear you got it working. I checked in a change to > QOCalcTriMeshEdges.cpp, removing the not. > > |
|
From: James W. W. <os...@jw...> - 2007-06-06 16:04:54
|
On Jun 6, 2007, at 2:22 AM, Daniele Cavallini wrote: > Do you think It will be possibile work with orthographic cameras into > future? I don't know how. The problem is that the shadow volume algorithm involves rendering infinite points, which requires setting yon to infinity. But there is no sensible way to set yon to infinity for an orthographic camera. > Is it possibile for object don't generate shadows? (example > handle). How > I can to do this? Yes. Create a cast-shadows style that specifies not casting a shadow. (Q3CastShadowsStyle_New( kQ3False )) Put this at the beginning of a group, and then later objects in that group will not cast shadows. |
|
From: James W. W. <os...@jw...> - 2007-06-07 06:02:47
|
On Jun 6, 2007, at 9:04 AM, James W. Walker wrote: > > On Jun 6, 2007, at 2:22 AM, Daniele Cavallini wrote: > >> Do you think It will be possibile work with orthographic cameras into >> future? > > I don't know how. The problem is that the shadow volume algorithm > involves rendering infinite points, which requires setting yon to > infinity. But there is no sensible way to set yon to infinity for an > orthographic camera. I read something saying that if you have the GL_NV_depth_clamp extension, you can do it without an infinite yon. |
|
From: James W. <ja...@fr...> - 2007-06-08 19:22:11
|
James W. Walker wrote: > On Jun 6, 2007, at 9:04 AM, James W. Walker wrote: > >> On Jun 6, 2007, at 2:22 AM, Daniele Cavallini wrote: >> >>> Do you think It will be possibile work with orthographic cameras into >>> future? >> I don't know how. The problem is that the shadow volume algorithm >> involves rendering infinite points, which requires setting yon to >> infinity. But there is no sensible way to set yon to infinity for an >> orthographic camera. > > I read something saying that if you have the GL_NV_depth_clamp > extension, you can do it without an infinite yon. Daniele, you might want to try it with an orthographic camera. On the 6th, I changed the shadow code so that it does not use infinite yon if the camera is orthographic, and the code already uses GL_NV_depth_clamp if that extension is available. -- James W. Walker, Innoventive Software LLC <http://www.frameforge3d.com/> |
|
From: Daniele C. <dca...@in...> - 2007-06-11 07:24:46
|
Great! It seem works very well. James Walker ha scritto: > James W. Walker wrote: > >> On Jun 6, 2007, at 9:04 AM, James W. Walker wrote: >> >> >>> On Jun 6, 2007, at 2:22 AM, Daniele Cavallini wrote: >>> >>> >>>> Do you think It will be possibile work with orthographic cameras into >>>> future? >>>> >>> I don't know how. The problem is that the shadow volume algorithm >>> involves rendering infinite points, which requires setting yon to >>> infinity. But there is no sensible way to set yon to infinity for an >>> orthographic camera. >>> >> I read something saying that if you have the GL_NV_depth_clamp >> extension, you can do it without an infinite yon. >> > > Daniele, you might want to try it with an orthographic camera. On the > 6th, I changed the shadow code so that it does not use infinite yon if > the camera is orthographic, and the code already uses GL_NV_depth_clamp > if that extension is available. > |