Incorrect Incident ray direction in orthogonal projection
|
View:
New views
10 Messages
—
Rating Filter:
Alert me
|
 |
Incorrect Incident ray direction in orthogonal projection
by Ricardo Mayor
::
Rate this Message:
Hello,
I've been trying to solve the bug ID: 2811280 "fog not working with orthographic perspective" and I have discovered that the Incident Ray direccion is not well defined in the orthographic perspective. Bug Description: "Attached is an example of fog volume shading not working properly with orthographic perspectives (either its not present or scaled wrong, hard to tell)." The attached rib is a simple scene with a cube that use the volume shader "fog" with color (0,0,1) . When this example is rendered in perspective , the cube is blue, which is right. In the orthogonal perspective, the cube is rendered in gray. In this case, It seems that the volume shader is not working. The fog shader is using the Incident ray direction (I) to measure the distance between the camera and the point shaded but in the orthogonal perspective this vector is always defined as (0,0,1). This is not correct IMO. I think the correct value is (0,0,Z). Z is the distance between the projection plane and the shaded surface. I found an interesting discussion in comp.graphics.rendering.renderman related with this issue. http://groups.google.es/group/comp.graphics.rendering.renderman/browse_thread/thread/11700c649706947f/b5d7b952eb46dfa9?hl=es&ie=UTF-8&pli=1 In one of the post, the "I" vector is defined as I propose: http://groups.google.es/group/comp.graphics.rendering.renderman/msg/507c52f4da977b8d?hl=es I've attached a patch with my proposed aproach. Best regards [orthogonal_error.patch] --- src/libs/core/micropolygon.cpp 2009-08-20 21:43:45.899223002 +0100 +++ notas_personales/orthofog_test/micropolygon.cpp 2009-08-20 21:43:33.414225524 +0100 @@ -411,7 +411,10 @@ switch(QGetRenderContext()->GetIntegerOption("System", "Projection")[0]) { case ProjectionOrthographic: - pI->SetVector(CqVector3D(0,0,1)); + + const CqVector3D * pData; + (pVar(EnvVars_P))->GetVectorPtr( pData ); + pI->SetVector(CqVector3D(0,0,pData->z())); break; case ProjectionPerspective: default: ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ Aqsis-development mailing list Aqsis-development@... https://lists.sourceforge.net/lists/listinfo/aqsis-development |
|
|
Re: Incorrect Incident ray direction in orthogonal projection
by Jonathan Merritt-2
::
Rate this Message:
Hi Ricardo,
Just a quick note about this; it might be worthwhile also submitting your patch at the SourceForge site: http://sourceforge.net/tracker/?group_id=25264&atid=383972 and putting a note about it in the bug tracker too: http://sourceforge.net/tracker/?func=detail&aid=2811280&group_id=25264&atid=383970 Chris and Paul are doing most of the trunk development work at the moment, and if they're busy with other things, there's a good chance that there might be a short delay before they can check out your patch. If it's logged with the bug at SourceForge then it will be more readily on-hand later on (and most importantly: it won't be forgotten accidentally! :-). Jonathan Merritt. On 21/08/2009, at 7:48 AM, Ricardo Mayor wrote: > Hello, > I've been trying to solve the bug ID: 2811280 "fog not working with > orthographic perspective" and I have discovered that the Incident > Ray direccion is not well defined in the orthographic perspective. > > Bug Description: > "Attached is an example of fog volume shading not working properly > with > orthographic perspectives (either its not present or scaled wrong, > hard to > tell)." > > The attached rib is a simple scene with a cube that use the volume > shader "fog" with color (0,0,1) . When this example is rendered in > perspective , the cube is blue, which is right. In the orthogonal > perspective, the cube is rendered in gray. In this case, It seems > that the volume shader is not working. > > The fog shader is using the Incident ray direction (I) to measure > the distance between the camera and the point shaded but in the > orthogonal perspective this vector is always defined as (0,0,1). > This is not correct IMO. I think the correct value is (0,0,Z). Z is > the distance between the projection plane and the shaded surface. > > I found an interesting discussion in > comp.graphics.rendering.renderman related with this issue. > > http://groups.google.es/group/comp.graphics.rendering.renderman/browse_thread/thread/11700c649706947f/b5d7b952eb46dfa9?hl=es&ie=UTF-8&pli=1 > > In one of the post, the "I" vector is defined as I propose: > > http://groups.google.es/group/comp.graphics.rendering.renderman/msg/507c52f4da977b8d?hl=es > > I've attached a patch with my proposed aproach. > > Best regards > < > orthogonal_error > .patch > > > ------------------------------------------------------------------------------ > Let Crystal Reports handle the reporting - Free Crystal Reports 2008 > 30-Day > trial. Simplify your report design, integration and deployment - and > focus on > what you do best, core application coding. Discover what's new with > Crystal Reports now. http://p.sf.net/sfu/bobj-july_______________________________________________ > Aqsis-development mailing list > Aqsis-development@... > https://lists.sourceforge.net/lists/listinfo/aqsis-development ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ Aqsis-development mailing list Aqsis-development@... https://lists.sourceforge.net/lists/listinfo/aqsis-development |
|
|
Re: Incorrect Incident ray direction in orthogonal projection
by Chris Foster-5
::
Rate this Message:
On Fri, Aug 21, 2009 at 7:48 AM, Ricardo Mayor<ricardo.mayor@...> wrote:
> The fog shader is using the Incident ray direction (I) to measure the > distance between the camera and the point shaded but in the orthogonal > perspective this vector is always defined as (0,0,1). > This is not correct IMO. I think the correct value is (0,0,Z). Z is the > distance between the projection plane and the shaded surface. Yep, you're quite right about this, nice work :-) The usenet links are very welcome too. > I've attached a patch with my proposed aproach. Your patch implemented the right kind of idea, but wasn't quite correct. Let me explain... Shading is done for an entire grid of points at once. This means that the variables I and P which you've got in the patch actually represent an *array* of CqVector3D with length equal to the number of vertices on the current grid. This means that for orthogonal projections we really need to set the values in I as follows (taken from the final patch which is now committed to the trunk): case ProjectionOrthographic: { const CqVector3D* pP = 0; pVar(EnvVars_P)->GetPointPtr(pP); CqVector3D* pI = 0; pVar(EnvVars_I)->GetVectorPtr(pI); for(TqInt i = 0; i < gs; ++i) pI[i] = CqVector3D(0,0,pP[i].z()); } BTW, if you're considering investigating more bugs, here's a list of some which I'd suggest *may* be reasonably easy to deal with (no guarentee!): 2563908 RiExposure has no effect on empty buckets 2730585 RiProjection doesn't accept RI_NULL as projection 2731390 RiBlobby Issue 2738390 Transformations prior to a RiProjection() call are ignored 2474067 DoF not implemented for RiPoints 2474255 DoF artifacts at image edges 2813534 Escaped strings in RSL not working Cheers, ~Chris. ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ Aqsis-development mailing list Aqsis-development@... https://lists.sourceforge.net/lists/listinfo/aqsis-development |
|
|
Re: Incorrect Incident ray direction in orthogonal projection
by Paul Gregory-4
::
Rate this Message:
Can I just add my thanks too, it's nice to see new people looking at the bugs database. Normally it's just us core developers who end up dealing with that. In reality, the bugs, especially the 'surface' ones that Chris has pointed out, are an excellent way to get familiar with the codebase, and undoubtedly the best way to endear yourself to the community and the developers.
So, in closing, your efforts are welcome, and appreciated. Paul ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ Aqsis-development mailing list Aqsis-development@... https://lists.sourceforge.net/lists/listinfo/aqsis-development |
|
|
Re: Incorrect Incident ray direction in orthogonal projection
by Ricardo Mayor
::
Rate this Message:
You are welcome. I started with the bugs database because I think it's a good start point. My intention is to be part of this project. I'll take note of the suggested bug list. Anyway, now I´m dealing with the error #2811294 "environment("blur") between cube faces". I think I have identified the problem and I'm looking how the code works. As soon I have something clear I'll send a report.
Best regards On Sat, Aug 22, 2009 at 12:31 PM, Paul Gregory <pgregory@...> wrote: Can I just add my thanks too, it's nice to see new people looking at the bugs database. Normally it's just us core developers who end up dealing with that. In reality, the bugs, especially the 'surface' ones that Chris has pointed out, are an excellent way to get familiar with the codebase, and undoubtedly the best way to endear yourself to the community and the developers. ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ Aqsis-development mailing list Aqsis-development@... https://lists.sourceforge.net/lists/listinfo/aqsis-development |
|
|
Re: Incorrect Incident ray direction in orthogonal projection
by Chris Foster-5
::
Rate this Message:
On Mon, Aug 24, 2009 at 7:55 PM, Ricardo Mayor<ricardo.mayor@...> wrote:
> You are welcome. I started with the bugs database because I think it's a > good start point. My intention is to be part of this project. I'll take note > of the suggested bug list. Anyway, now I´m dealing with the error #2811294 > "environment("blur") between cube faces". I think I have identified the > problem and I'm looking how the code works. As soon I have something clear > I'll send a report. Ah, this is a tricky one. I can tell you exactly what the problem is, because I wrote that code ;-) I'm just not sure how best to go about fixing it yet. Cube face environment filtering is done by mapping a direction onto the appropriate face of the cube. That's ok, but if the user has specified a really large blur then the filter size is large and it can end up overlapping onto more than one face of the cube. This implies doing part of the filtering operation on one face of the cube, part on another, and then adding the two partial filters together. Currently the code is blissfully unaware of this however, and just runs over the edge onto the adjacent face, causing artifacts. There's actually a provision in the RiMakeEnvironment call to avoid filtering problems: it's got a "fov" parameter which is meant to specify the field of view of the individual cube faces. Using fov > 90 will make the cube faces overlap and helps avoid filtering artifacts. When I originally wrote the code, I thought this was for use with large blur widths but it seems now that I may have been mistaken... Anyway, the fix will be to make the filtering code aware of the cube face boundaries; if the filter area falls across a boundary then it needs to do extra computation by filtering on each cube face individually and adding the results together somehow. With stochastic filtering this would be fairly easy - if inefficient - because you could look up the appropriate cube face for each texture access. For the current elliptical filtering method I'm worried that it will be difficult to join the faces together without artifacts :-/ ~Chris. ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ Aqsis-development mailing list Aqsis-development@... https://lists.sourceforge.net/lists/listinfo/aqsis-development |
|
|
Re: Incorrect Incident ray direction in orthogonal projection
by Ricardo Mayor
::
Rate this Message:
OK, I see the problem. I've been thinking in the stochastic sampled as the most accurate method to fix this issue. But, as you say, is probably the most inefficient. IMO the only reason to implement this method is if blurring large areas is a common case, but I don't think so.
Anyway, I don't know if it's better to continue with this issue or start with other ones. What do you think? On Tue, Aug 25, 2009 at 1:56 AM, Chris Foster <chris42f@...> wrote:
------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ Aqsis-development mailing list Aqsis-development@... https://lists.sourceforge.net/lists/listinfo/aqsis-development |
|
|
Re: Incorrect Incident ray direction in orthogonal projection
by Chris Foster-5
::
Rate this Message:
On Tue, Aug 25, 2009 at 4:58 PM, Ricardo Mayor<ricardo.mayor@...> wrote:
> OK, I see the problem. I've been thinking in the stochastic sampled as the > most accurate method to fix this issue. Actually, no I don't believe stochastic filtering is the most accurate, but it's easy to implement! EWA filtering is very high quality and extremely well-motivated mathematically - the theory appears in Paul Heckbert's masters thesis if you're interested (http://www.cs.cmu.edu/~ph/). The trick here will be the efficient stitching of partial filtering results between two cube faces... > But, as you say, is probably the > most inefficient. IMO the only reason to implement this method is if > blurring large areas is a common case, but I don't think so. We need to provide accurate results, so clearly we need to do something about the blurring issue - it can't be swept under the carpet. My preference is for a clever fix to the current EWA filtering system. > Anyway, I don't know if it's better to continue with this issue or start > with other ones. > > What do you think? I think you've chosen quite a hard bug with this one ;-) If you want to work on it, I'm happy to provide suggestions and help out with details - it will eventually fall to me to fix this issue anyway. OTOH, if you want something which is a bit easier to solve I'd suggest having a look at the issues on the list I sent a few mails ago. For instance, fixing the RiExposure issue should be nicely self-contained. Cheers, ~Chris. ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ Aqsis-development mailing list Aqsis-development@... https://lists.sourceforge.net/lists/listinfo/aqsis-development |
|
|
Re: Incorrect Incident ray direction in orthogonal projection
by Chris Foster-5
::
Rate this Message:
On Tue, Aug 25, 2009 at 5:45 PM, Chris Foster<chris42f@...> wrote:
> Actually, no I don't believe stochastic filtering is the most > accurate, but it's easy to implement! I guess I should qualify this statement... stochastic filtering is potentially the most accurate because it has the ability to treat an arbitrary texture warp exactly... unlike elliptical filtering (EWA) which uses a linear approximation to the texture warp at the current point. However, the texture reconstruction filter is quite arbitrary (do we choose bilinear, bicubic, gaussian, etc?) so although stochastic filtering can represent the warping transformation exactly, it's not clear whether the filtering process as a whole would be any better. ~Chris. ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ Aqsis-development mailing list Aqsis-development@... https://lists.sourceforge.net/lists/listinfo/aqsis-development |
|
|
Re: Incorrect Incident ray direction in orthogonal projection
by Ricardo Mayor
::
Rate this Message:
Ok, I'll take a look at the Riexposure issue. I don't want to burn all the fuel at the beginning.
On Tue, Aug 25, 2009 at 8:45 AM, Chris Foster <chris42f@...> wrote:
------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ Aqsis-development mailing list Aqsis-development@... https://lists.sourceforge.net/lists/listinfo/aqsis-development |
| Free embeddable forum powered by Nabble | Forum Help |
