Menu
▾
▴
quesa-develop — Mailing list for Quesa development
This list is closed, nobody may subscribe to it.
| 2004 |
Jan
(7) |
Feb
(117) |
Mar
(37) |
Apr
(46) |
May
(14) |
Jun
(255) |
Jul
(100) |
Aug
(76) |
Sep
(65) |
Oct
(38) |
Nov
(49) |
Dec
(41) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2005 |
Jan
(106) |
Feb
(70) |
Mar
(9) |
Apr
(4) |
May
(42) |
Jun
(29) |
Jul
(106) |
Aug
(38) |
Sep
(11) |
Oct
(31) |
Nov
(14) |
Dec
(14) |
| 2006 |
Jan
(2) |
Feb
(9) |
Mar
(15) |
Apr
(13) |
May
(16) |
Jun
(5) |
Jul
(11) |
Aug
(1) |
Sep
(7) |
Oct
|
Nov
(9) |
Dec
(1) |
| 2007 |
Jan
(13) |
Feb
(107) |
Mar
(43) |
Apr
(43) |
May
(38) |
Jun
(38) |
Jul
(63) |
Aug
|
Sep
(30) |
Oct
(52) |
Nov
(4) |
Dec
(10) |
| 2008 |
Jan
(12) |
Feb
(10) |
Mar
(5) |
Apr
(3) |
May
(15) |
Jun
(2) |
Jul
|
Aug
(10) |
Sep
(20) |
Oct
(6) |
Nov
|
Dec
(6) |
| 2009 |
Jan
(1) |
Feb
(5) |
Mar
(3) |
Apr
(51) |
May
|
Jun
|
Jul
|
Aug
(14) |
Sep
|
Oct
|
Nov
|
Dec
(4) |
| 2010 |
Jan
(9) |
Feb
|
Mar
(8) |
Apr
|
May
(2) |
Jun
|
Jul
|
Aug
(1) |
Sep
(3) |
Oct
|
Nov
|
Dec
|
| 2011 |
Jan
|
Feb
|
Mar
(9) |
Apr
|
May
|
Jun
|
Jul
|
Aug
(1) |
Sep
|
Oct
|
Nov
(7) |
Dec
(1) |
| 2012 |
Jan
|
Feb
(6) |
Mar
(3) |
Apr
|
May
(6) |
Jun
(5) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2013 |
Jan
|
Feb
|
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2018 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
|
Dec
|
|
From: James W. <ja...@fr...> - 2010-03-19 17:40:51
|
Let's say you have a TriMesh that is subject to an orientation-reversing transformation (mirror image). If you use a backface culling style, then the wrong side will be culled, and even if you don't, the geometry will look weird due to the vertex normals being reversed. However, you can compensate by introducing a clockwise orientation style. With the higher-level geometries like Cylinder, this doesn't work, because they have a built-in counterclockwise orientation style. This was done in 2003 by Dair Grant, in accordance with QD3D documentation on orientation styles, but it seems problematic to me. Comments? -- James W. Walker, Innoventive Software LLC <http://www.frameforge3d.com/> |
|
From: Edward K. C. <ek...@lg...> - 2010-03-16 17:18:46
|
On 2010-03-15, at 4:01 PM, James Walker wrote: > On 3/15/2010 11:03 AM, Edward K. Chew wrote: > >> Just wondering if there is any sample code for creating texture maps >> using CGBitmapContext and the like? I think I see what I need to do, >> but there may be some potential gotchas and most of the examples I've >> come across seem to deal with Quickdraw-era stuff like gworlds. >> Basically, what it comes down to is I have a client who wants to be >> able to import PDFs into rectangular sheets floating around in the 3D >> model, and Quickdraw is not so great with PDFs. > > I don't think I have any good sample code I could post... I'm using a > somewhat convoluted scheme where a framework calls an application > callback to get pixel data, which might be from a CGBitmapContext, and > then passes it to Quesa. But I could discuss any issues you're worried > about. > > -- > James W. Walker, Innoventive Software LLC > <http://www.frameforge3d.com/> Thanks James. Well, I guess I'll press ahead with what I've got and let you know if I hit a snag. -Ted |
|
From: James W. <ja...@fr...> - 2010-03-15 20:28:21
|
On 3/15/2010 11:03 AM, Edward K. Chew wrote: > Just wondering if there is any sample code for creating texture maps > using CGBitmapContext and the like? I think I see what I need to do, > but there may be some potential gotchas and most of the examples I've > come across seem to deal with Quickdraw-era stuff like gworlds. > Basically, what it comes down to is I have a client who wants to be > able to import PDFs into rectangular sheets floating around in the 3D > model, and Quickdraw is not so great with PDFs. I don't think I have any good sample code I could post... I'm using a somewhat convoluted scheme where a framework calls an application callback to get pixel data, which might be from a CGBitmapContext, and then passes it to Quesa. But I could discuss any issues you're worried about. -- James W. Walker, Innoventive Software LLC <http://www.frameforge3d.com/> |
|
From: Edward K. C. <ek...@lg...> - 2010-03-15 18:30:05
|
Just wondering if there is any sample code for creating texture maps using CGBitmapContext and the like? I think I see what I need to do, but there may be some potential gotchas and most of the examples I've come across seem to deal with Quickdraw-era stuff like gworlds. Basically, what it comes down to is I have a client who wants to be able to import PDFs into rectangular sheets floating around in the 3D model, and Quickdraw is not so great with PDFs. -Ted |
|
From: James W. <ja...@fr...> - 2010-01-21 20:29:44
|
On 1/21/2010 11:11 AM, Stefan Huber wrote: > The following problem is related to nearly all renderers (exept for > Quesa Interactive). > > The attached model contains three sheared boxes. Two of them are > semitranparent. When I rotate the model, all the boxes disappear > sometimes if the camera is near the model. The nearer the camera the > more problems. > > The problem has been introduced between 2009-05-14 and 2009-12-20. I've committed a change that seems to fix it. -- James W. Walker, Innoventive Software LLC <http://www.frameforge3d.com/> |
|
From: Stefan H. <st...@to...> - 2010-01-21 19:16:32
|
The following problem is related to nearly all renderers (exept for Quesa Interactive). The attached model contains three sheared boxes. Two of them are semitranparent. When I rotate the model, all the boxes disappear sometimes if the camera is near the model. The nearer the camera the more problems. The problem has been introduced between 2009-05-14 and 2009-12-20. Stefan http://www.topoi.ch |
|
From: Stefan H. <st...@to...> - 2010-01-21 19:11:59
|
The following problem is related to nearly all renderers (exept for Quesa Interactive). The attached model contains three sheared boxes. Two of them are semitranparent. When I rotate the model, all the boxes disappear sometimes if the camera is near the model. The nearer the camera the more problems. The problem has been introduced between 2009-05-14 and 2009-12-20. Stefan http://www.topoi.ch |
|
From: James W. W. <os...@jw...> - 2010-01-16 06:48:12
|
On Jan 15, 2010, at 12:30 AM, Daniele Cavallini wrote: > Thank you! > I think download page of quesa.org should be updated. You're right, I have updated it. I have also disabled the CVS access on SourceForge. > > > James W. Walker ha scritto: >> On Jan 14, 2010, at 9:04 AM, Daniele Cavallini wrote: >> >> >>> I compiled last release from cvs : >>> >>> cvs -d :pserver:ano...@qu...:/cvsroot/quesa login >>> cvs -d :pserver:ano...@qu...:/cvsroot/quesa -z 9 co quesa >>> >>> Is it right? >>> >> >> >> That's old, you should be using svn. >> >> >> >>> I use Visual Studio 2008 >>> >> >> >> I used CodeWarrior. >> >> >> >>> James Walker ha scritto: >>> >>>> On 1/13/2010 1:48 AM, Daniele Cavallini wrote: >>>> >>>> >>>>> There is a problem with windows version of quesa when used quesa >>>>> interactive render. >>>>> You can try to run geom test. When you try to select "Quesa interactive" >>>>> from menù render app crash. >>>>> If used quesa.dll debug there isn't problem. >>>>> >>>>> >>>> A release build of quesa.dll running the interactive render does not >>>> crash on Windows (Vista Home Premium 64-bit) for me. >>>> >>>> >>>> >>>> >>>>> I ask if is useful to maintain this type of rendering. I use a work >>>>> around to resolve the problem. >>>>> If chosen interactive I set Quesa Opengl with shadows disabled. >>>>> >>>>> >>>> You could think of the interactive renderer as the "legacy renderer". >>>> It might be more faithful to the behavior of QuickDraw 3D in a few >>>> cases, but in most cases the OpenGL renderer is superior. >>>> >>>> >>>> >>> ------------------------------------------------------------------------------ >>> Throughout its 18-year history, RSA Conference consistently attracts the >>> world's best and brightest in the field, creating opportunities for Conference >>> attendees to learn about information security's most important issues through >>> interactions with peers, luminaries and emerging and established companies. >>> http://p.sf.net/sfu/rsaconf-dev2dev >>> _______________________________________________ >>> Quesa-develop mailing list >>> Que...@li... >>> https://lists.sourceforge.net/lists/listinfo/quesa-develop >>> >> >> >> ------------------------------------------------------------------------------ >> Throughout its 18-year history, RSA Conference consistently attracts the >> world's best and brightest in the field, creating opportunities for Conference >> attendees to learn about information security's most important issues through >> interactions with peers, luminaries and emerging and established companies. >> http://p.sf.net/sfu/rsaconf-dev2dev >> _______________________________________________ >> Quesa-develop mailing list >> Que...@li... >> https://lists.sourceforge.net/lists/listinfo/quesa-develop >> >> > > > ------------------------------------------------------------------------------ > Throughout its 18-year history, RSA Conference consistently attracts the > world's best and brightest in the field, creating opportunities for Conference > attendees to learn about information security's most important issues through > interactions with peers, luminaries and emerging and established companies. > http://p.sf.net/sfu/rsaconf-dev2dev > _______________________________________________ > Quesa-develop mailing list > Que...@li... > https://lists.sourceforge.net/lists/listinfo/quesa-develop |
|
From: Daniele C. <dca...@in...> - 2010-01-15 08:30:53
|
Thank you! I think download page of quesa.org should be updated. James W. Walker ha scritto: > On Jan 14, 2010, at 9:04 AM, Daniele Cavallini wrote: > > >> I compiled last release from cvs : >> >> cvs -d :pserver:ano...@qu...:/cvsroot/quesa login >> cvs -d :pserver:ano...@qu...:/cvsroot/quesa -z 9 co quesa >> >> Is it right? >> > > > That's old, you should be using svn. > > > >> I use Visual Studio 2008 >> > > > I used CodeWarrior. > > > >> James Walker ha scritto: >> >>> On 1/13/2010 1:48 AM, Daniele Cavallini wrote: >>> >>> >>>> There is a problem with windows version of quesa when used quesa >>>> interactive render. >>>> You can try to run geom test. When you try to select "Quesa interactive" >>>> from menù render app crash. >>>> If used quesa.dll debug there isn't problem. >>>> >>>> >>> A release build of quesa.dll running the interactive render does not >>> crash on Windows (Vista Home Premium 64-bit) for me. >>> >>> >>> >>> >>>> I ask if is useful to maintain this type of rendering. I use a work >>>> around to resolve the problem. >>>> If chosen interactive I set Quesa Opengl with shadows disabled. >>>> >>>> >>> You could think of the interactive renderer as the "legacy renderer". >>> It might be more faithful to the behavior of QuickDraw 3D in a few >>> cases, but in most cases the OpenGL renderer is superior. >>> >>> >>> >> ------------------------------------------------------------------------------ >> Throughout its 18-year history, RSA Conference consistently attracts the >> world's best and brightest in the field, creating opportunities for Conference >> attendees to learn about information security's most important issues through >> interactions with peers, luminaries and emerging and established companies. >> http://p.sf.net/sfu/rsaconf-dev2dev >> _______________________________________________ >> Quesa-develop mailing list >> Que...@li... >> https://lists.sourceforge.net/lists/listinfo/quesa-develop >> > > > ------------------------------------------------------------------------------ > Throughout its 18-year history, RSA Conference consistently attracts the > world's best and brightest in the field, creating opportunities for Conference > attendees to learn about information security's most important issues through > interactions with peers, luminaries and emerging and established companies. > http://p.sf.net/sfu/rsaconf-dev2dev > _______________________________________________ > Quesa-develop mailing list > Que...@li... > https://lists.sourceforge.net/lists/listinfo/quesa-develop > > |
|
From: James W. W. <os...@jw...> - 2010-01-14 17:27:32
|
On Jan 14, 2010, at 9:04 AM, Daniele Cavallini wrote: > I compiled last release from cvs : > > cvs -d :pserver:ano...@qu...:/cvsroot/quesa login > cvs -d :pserver:ano...@qu...:/cvsroot/quesa -z 9 co quesa > > Is it right? That's old, you should be using svn. > I use Visual Studio 2008 I used CodeWarrior. > > James Walker ha scritto: >> On 1/13/2010 1:48 AM, Daniele Cavallini wrote: >> >>> There is a problem with windows version of quesa when used quesa >>> interactive render. >>> You can try to run geom test. When you try to select "Quesa interactive" >>> from menù render app crash. >>> If used quesa.dll debug there isn't problem. >>> >> >> >> A release build of quesa.dll running the interactive render does not >> crash on Windows (Vista Home Premium 64-bit) for me. >> >> >> >>> I ask if is useful to maintain this type of rendering. I use a work >>> around to resolve the problem. >>> If chosen interactive I set Quesa Opengl with shadows disabled. >>> >> >> >> You could think of the interactive renderer as the "legacy renderer". >> It might be more faithful to the behavior of QuickDraw 3D in a few >> cases, but in most cases the OpenGL renderer is superior. >> >> > > > ------------------------------------------------------------------------------ > Throughout its 18-year history, RSA Conference consistently attracts the > world's best and brightest in the field, creating opportunities for Conference > attendees to learn about information security's most important issues through > interactions with peers, luminaries and emerging and established companies. > http://p.sf.net/sfu/rsaconf-dev2dev > _______________________________________________ > Quesa-develop mailing list > Que...@li... > https://lists.sourceforge.net/lists/listinfo/quesa-develop |
|
From: Daniele C. <dca...@in...> - 2010-01-14 17:05:00
|
I compiled last release from cvs : cvs -d :pserver:ano...@qu...:/cvsroot/quesa login cvs -d :pserver:ano...@qu...:/cvsroot/quesa -z 9 co quesa Is it right? I use Visual Studio 2008 James Walker ha scritto: > On 1/13/2010 1:48 AM, Daniele Cavallini wrote: > >> There is a problem with windows version of quesa when used quesa >> interactive render. >> You can try to run geom test. When you try to select "Quesa interactive" >> from menù render app crash. >> If used quesa.dll debug there isn't problem. >> > > > A release build of quesa.dll running the interactive render does not > crash on Windows (Vista Home Premium 64-bit) for me. > > > >> I ask if is useful to maintain this type of rendering. I use a work >> around to resolve the problem. >> If chosen interactive I set Quesa Opengl with shadows disabled. >> > > > You could think of the interactive renderer as the "legacy renderer". > It might be more faithful to the behavior of QuickDraw 3D in a few > cases, but in most cases the OpenGL renderer is superior. > > |
|
From: James W. <ja...@fr...> - 2010-01-13 19:42:07
|
On 1/13/2010 1:48 AM, Daniele Cavallini wrote: > There is a problem with windows version of quesa when used quesa > interactive render. > You can try to run geom test. When you try to select "Quesa interactive" > from menù render app crash. > If used quesa.dll debug there isn't problem. A release build of quesa.dll running the interactive render does not crash on Windows (Vista Home Premium 64-bit) for me. > I ask if is useful to maintain this type of rendering. I use a work > around to resolve the problem. > If chosen interactive I set Quesa Opengl with shadows disabled. You could think of the interactive renderer as the "legacy renderer". It might be more faithful to the behavior of QuickDraw 3D in a few cases, but in most cases the OpenGL renderer is superior. -- James W. Walker, Innoventive Software LLC <http://www.frameforge3d.com/> |
|
From: Daniele C. <dca...@in...> - 2010-01-13 10:09:27
|
There is a problem with windows version of quesa when used quesa interactive render. You can try to run geom test. When you try to select "Quesa interactive" from menù render app crash. If used quesa.dll debug there isn't problem. I ask if is useful to maintain this type of rendering. I use a work around to resolve the problem. If chosen interactive I set Quesa Opengl with shadows disabled. |
|
From: James W. W. <os...@jw...> - 2009-12-21 18:53:29
|
I've added a few new topics to the wiki: Draw Context Properties Renderer Properties Subclassing the View Object I'm not sure who is allowed to edit the wiki, other than me. If you try and fail to edit, let me know and I'll see if I can fix it. |
|
From: James W. W. <os...@jw...> - 2009-12-15 06:53:07
|
On Dec 12, 2009, at 5:59 AM, Stefan Huber wrote: > I can't find the Quesa Wiki (with all the infos about new features) > on sourgeforge.net anymore. Does anybody know more... The new wiki is open for business. The page you were probably looking for: <https://sourceforge.net/apps/mediawiki/quesa/index.php?title=OpenGL_Rendering_Effects> |
|
From: James W. W. <os...@jw...> - 2009-12-12 18:47:08
|
On Dec 12, 2009, at 5:59 AM, Stefan Huber wrote: > Hi all, > > I can't find the Quesa Wiki (with all the infos about new features) > on sourgeforge.net anymore. Does anybody know more... Apparently this summer SourceForge changed to different wiki software (now MediaWiki, like Wikipedia). The data from the old wiki was archived. I will see if I can figure out how to migrate it. |
|
From: Stefan H. <st...@to...> - 2009-12-12 15:05:00
|
Hi all, I can't find the Quesa Wiki (with all the infos about new features) on sourgeforge.net anymore. Does anybody know more... thanks, Stefan http://www.topoi.ch |
|
From: Sean M. <se...@ro...> - 2009-08-27 17:28:58
|
On 8/26/09 10:31 AM, James Walker said: >I have just committed a change to IRUpdate.c and IRPrefix.h to make the >IR do FSAA using plain GL calls, like the OpenGL renderer does. Thanks James! It's nice to have a working copy with no special changes. :0 -- ____________________________________________________________ Sean McBride, B. Eng se...@ro... Rogue Research www.rogue-research.com Mac Software Developer Montréal, Québec, Canada |
|
From: James W. <ja...@fr...> - 2009-08-26 17:31:59
|
Sean McBride wrote: > On 8/25/09 1:52 PM, James Walker said: > >>> No, it's not needed. The current way to do FSAA requires both a >>> kQ3AntiAliasModeMaskFullScreen style, and using >>> kQ3DrawContextPropertyGLPixelFormat to provide a pixel format that >>> supports multisampling. The Cocoa example program illustrates this. I >>> guess we don't have a Carbon sample that does it, but it's pretty much >>> the same. >> Oops, I oversimplified. IRUpdate.c would need to be updated to handle >> antialias styles like QOUpdate.cpp does. > > I must say I don't really follow (no doubt because I don't really know > what the code in question does, nor do I use it). Would it be feasible > to change it to use only plain-gl calls (or CGL) instead of AGL calls? I have just committed a change to IRUpdate.c and IRPrefix.h to make the IR do FSAA using plain GL calls, like the OpenGL renderer does. -- James W. Walker, Innoventive Software LLC <http://www.frameforge3d.com/> |
|
From: Sean M. <se...@ro...> - 2009-08-26 14:39:56
|
On 8/25/09 1:52 PM, James Walker said: >> No, it's not needed. The current way to do FSAA requires both a >> kQ3AntiAliasModeMaskFullScreen style, and using >> kQ3DrawContextPropertyGLPixelFormat to provide a pixel format that >> supports multisampling. The Cocoa example program illustrates this. I >> guess we don't have a Carbon sample that does it, but it's pretty much >> the same. > >Oops, I oversimplified. IRUpdate.c would need to be updated to handle >antialias styles like QOUpdate.cpp does. I must say I don't really follow (no doubt because I don't really know what the code in question does, nor do I use it). Would it be feasible to change it to use only plain-gl calls (or CGL) instead of AGL calls? -- ____________________________________________________________ Sean McBride, B. Eng se...@ro... Rogue Research www.rogue-research.com Mac Software Developer Montréal, Québec, Canada |
|
From: James W. <ja...@fr...> - 2009-08-25 20:52:59
|
James Walker wrote: > No, it's not needed. The current way to do FSAA requires both a > kQ3AntiAliasModeMaskFullScreen style, and using > kQ3DrawContextPropertyGLPixelFormat to provide a pixel format that > supports multisampling. The Cocoa example program illustrates this. I > guess we don't have a Carbon sample that does it, but it's pretty much > the same. Oops, I oversimplified. IRUpdate.c would need to be updated to handle antialias styles like QOUpdate.cpp does. -- James W. Walker, Innoventive Software LLC <http://www.frameforge3d.com/> |
|
From: James W. <ja...@fr...> - 2009-08-25 19:13:29
|
Sean McBride wrote: > I'm down to only 1 file different between svn and my local copy of Quesa: > > Development/Source/Renderers/Interactive/IRUpdate.c > > There is a comment: > > // Special-case FSAA support for ATI hardware on the Mac > // > // Should be extended to other cards/platforms as per bug 69, and > // use the ARB_multisample extension if present. > // > // http://cvs.designcommunity.com/bugzilla/show_bug.cgi?id=69 > #if QUESA_OS_MACINTOSH && ! QUESA_OS_COCOA > > > In my case, I get into this 'if'. Within the 'if', the code uses some > AGL APIs. However, that's the only place AGL is used (in my case) and > I'd rather not add a whole new framework to my app. > > Up till now I've just changed that to #if 0, but I wonder if there is a > better way. The bug it refers to seems old. Is the code even need > these days? No, it's not needed. The current way to do FSAA requires both a kQ3AntiAliasModeMaskFullScreen style, and using kQ3DrawContextPropertyGLPixelFormat to provide a pixel format that supports multisampling. The Cocoa example program illustrates this. I guess we don't have a Carbon sample that does it, but it's pretty much the same. -- James W. Walker, Innoventive Software LLC <http://www.frameforge3d.com/> |
|
From: Sean M. <se...@ro...> - 2009-08-25 18:46:42
|
Hi all, I'm down to only 1 file different between svn and my local copy of Quesa: Development/Source/Renderers/Interactive/IRUpdate.c There is a comment: // Special-case FSAA support for ATI hardware on the Mac // // Should be extended to other cards/platforms as per bug 69, and // use the ARB_multisample extension if present. // // http://cvs.designcommunity.com/bugzilla/show_bug.cgi?id=69 #if QUESA_OS_MACINTOSH && ! QUESA_OS_COCOA In my case, I get into this 'if'. Within the 'if', the code uses some AGL APIs. However, that's the only place AGL is used (in my case) and I'd rather not add a whole new framework to my app. Up till now I've just changed that to #if 0, but I wonder if there is a better way. The bug it refers to seems old. Is the code even need these days? Thanks, -- ____________________________________________________________ Sean McBride, B. Eng se...@ro... Rogue Research www.rogue-research.com Mac Software Developer Montréal, Québec, Canada |
|
From: James W. <ja...@fr...> - 2009-08-24 18:19:05
|
Roger Holmes wrote: > On 23 Aug 2009, at 17:48, James W. Walker wrote: > >> It occurs to me that a possible solution is to use the accumulation >> buffer, rather than blending, to add the contributions of multiple >> lighting passes. > > As long as your accumulation buffer has enough precision. Gut feeling > is for each component, floats or maybe 16 bit fixed would be OK but 8 > bits might show artefacts which should not be there. Good point. I'm also a little concerned about how using the accumulation buffer might affect speed. I've committed a hack to mostly solve my immediate problem. This change only changes the behavior of the OpenGL renderer if you have set kQ3RendererPropertyDepthAlphaThreshold. I may still experiment with the accumulation buffer scheme. -- James W. Walker, Innoventive Software LLC <http://www.frameforge3d.com/> |
|
From: Roger H. <rog...@mi...> - 2009-08-24 12:39:31
|
On 23 Aug 2009, at 17:48, James W. Walker wrote: > It occurs to me that a possible solution is to use the accumulation > buffer, rather than blending, to add the contributions of multiple > lighting passes. As long as your accumulation buffer has enough precision. Gut feeling is for each component, floats or maybe 16 bit fixed would be OK but 8 bits might show artefacts which should not be there. Roger. |
1 message has been excluded from this view by a project administrator.