Menu
▾
▴
quesa-develop
|
From: James W. <ja...@fr...> - 2007-01-27 02:58:03
|
I've mentioned before that I was thinking of writing a new renderer that would pay more attention to using OpenGL for best performance, and less attention to legacy behavior. I'm actually working on it now. It will probably be another couple of weeks before I'm ready to check anything in. The renderer nickname is tentatively "Quesa OpenGL Performance", but I'm open to suggestions. -- James W. Walker, Innoventive Software LLC <http://www.frameforge3d.com/> |
|
From: Jose' C. <cru...@ce...> - 2007-01-27 14:15:32
|
Il giorno 27/gen/07, alle ore 03:57, James Walker ha scritto: > I've mentioned before that I was thinking of writing a new renderer > that > would pay more attention to using OpenGL for best performance, and > less attention to legacy behavior. In the process will be a good thing to factor better the various functionality to ease the process to creatre new renderers. just separate things in various files that can be included in the compilation of new renderers,,, > I'm actually working on it now. It > will probably be another couple of weeks before I'm ready to check > anything in. I'm in the process of add wxWidgets as new platform , so it can be also a couple of weeks before we can see anything > The renderer nickname is tentatively "Quesa OpenGL > Performance", but I'm open to suggestions. just "Quesa OpenGL" ? Pax et Bonum # dott. Jose' Cruanyes Aguilar - C.E. Soft srl # Pzza. Firenze,4 MILANO - XX Settembre 10, CREMONA # 02,33603122 0372,460602 |
|
From: James W. <ja...@fr...> - 2007-01-29 18:51:21
|
Jose' Cruanyes wrote: > Il giorno 27/gen/07, alle ore 03:57, James Walker ha scritto: > >> I've mentioned before that I was thinking of writing a new renderer >> that >> would pay more attention to using OpenGL for best performance, and >> less attention to legacy behavior. > > In the process will be a good thing to factor better the various > functionality to ease the process to creatre new renderers. > > just separate things in various files that can be included in the > compilation of new renderers,,, I'll see what I can do. I'd like to figure out a way for something like the cartoon renderer to be a plug-in, which may require adding a couple more renderer methods. > I'm in the process of add wxWidgets as new platform , so it can be > also a couple of weeks before we can see anything I wouldn't have expected wxWidgets to be a platform, not that I know anything about it. Doesn't it use Carbon or Cocoa under the hood? >> The renderer nickname is tentatively "Quesa OpenGL >> Performance", but I'm open to suggestions. > > just "Quesa OpenGL" ? Hmm, yes, that might be better. -- James W. Walker, Innoventive Software LLC <http://www.frameforge3d.com/> |
|
From: Jose' C. <cru...@ce...> - 2007-01-29 22:19:44
|
Il giorno 29/gen/07, alle ore 19:50, James Walker ha scritto: > Jose' Cruanyes wrote: >> Il giorno 27/gen/07, alle ore 03:57, James Walker ha scritto: >> >>> I've mentioned before that I was thinking of writing a new renderer >>> that >>> would pay more attention to using OpenGL for best performance, and >>> less attention to legacy behavior. >> >> In the process will be a good thing to factor better the various >> functionality to ease the process to creatre new renderers. >> >> just separate things in various files that can be included in the >> compilation of new renderers,,, > > I'll see what I can do. I'd like to figure out a way for something > like > the cartoon renderer to be a plug-in, which may require adding a > couple > more renderer methods. It's not just a matter of compile it using some bits of the Quesa source? anyway they are always avalaible... or there are some deep interaction "broking the rules" between view and renderer? > >> I'm in the process of add wxWidgets as new platform , so it can be >> also a couple of weeks before we can see anything > > I wouldn't have expected wxWidgets to be a platform, not that I know > anything about it. Doesn't it use Carbon or Cocoa under the hood? and Win32, gtk, fbd, OS2, VMS and a couple of others, but since it has already factored out the platform differences, makes sense to use it as a platform from the Quesa point of view, especially when dealing with high level constructs like the viewer, or more mundane tools like files, windows ecc (yes, OpenGL surface/context are present) > >>> The renderer nickname is tentatively "Quesa OpenGL >>> Performance", but I'm open to suggestions. >> >> just "Quesa OpenGL" ? > > Hmm, yes, that might be better. > -- > James W. Walker, Innoventive Software LLC > <http://www.frameforge3d.com/> > > ---------------------------------------------------------------------- > --- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to > share your > opinions on IT & business topics through brief surveys - and earn cash > http://www.techsay.com/default.php? > page=join.php&p=sourceforge&CID=DEVDEV > _______________________________________________ > Quesa-develop mailing list > Que...@li... > https://lists.sourceforge.net/lists/listinfo/quesa-develop > Pax et Bonum # dott. Jose' Cruanyes Aguilar - C.E. Soft srl # Pzza. Firenze,4 MILANO - XX Settembre 10, CREMONA # 02,33603122 0372,460602 |
|
From: James W. <ja...@fr...> - 2007-01-30 02:58:55
|
Jose' Cruanyes wrote: > Il giorno 29/gen/07, alle ore 19:50, James Walker ha scritto: > >> Jose' Cruanyes wrote: >>> Il giorno 27/gen/07, alle ore 03:57, James Walker ha scritto: >>> >>>> I've mentioned before that I was thinking of writing a new renderer >>>> that >>>> would pay more attention to using OpenGL for best performance, and >>>> less attention to legacy behavior. >>> In the process will be a good thing to factor better the various >>> functionality to ease the process to creatre new renderers. >>> >>> just separate things in various files that can be included in the >>> compilation of new renderers,,, >> I'll see what I can do. I'd like to figure out a way for something >> like >> the cartoon renderer to be a plug-in, which may require adding a >> couple >> more renderer methods. > > It's not just a matter of compile it using some bits of the Quesa > source? > anyway they are always avalaible... or there are some deep > interaction "broking the rules" between view and renderer? Of course one could copy the entire source of the IR to make a new renderer, but in the case of the cartoon render, a very large amount would be the same. In attempting to subclass a renderer, the problem is with the way the attribute set of a geometry is handled. The submit-triangle and submit-trimesh methods need to call IRGeometry_Attribute_Handler and IRRenderer_Texture_Postamble, which are not available to a plugin subclass. -- James W. Walker, Innoventive Software LLC <http://www.frameforge3d.com/> |
|
From: Roger H. <rog...@mi...> - 2007-01-30 17:16:34
|
Hi All,
I like the sound of this new OpenGL optimised renderer.
Could someone see if they agree with what appears to be
a memory leak in E3AttributeSet_Inherit. I have a provisional
fix which is:
In this section of code, change the last but one line
// Process the child
if ( qd3dStatus == kQ3Success )
{
// Copy the mask and attributes directly
resultSet->setData.theMask = childSet->setData.theMask ;
resultSet->setData.attributes = childSet->setData.attributes ;
if ( resultSet->setData.attributes.surfaceShader != NULL )
resultSet->setData.attributes.surfaceShader =
Q3Shared_GetReference ( childSet->setData.attributes.surfaceShader ) ;
to read:
if ( resultSet->setData.attributes.surfaceShader != NULL && result !
= child )
When E3AttributeSet_Inherit gets called with child == result, the
reference count of surface
shaders gets incremented incorrectly, which loses huge amounts of
memory with even
modest sized textures if you call this routine a lot, which I do when
doing the CSG
calculations for windows and doors within walls, which is now done
for almost every time
redraw.
If you agree with the change, could you check it in, or remind me how
to do it
as I have not done a Quesa check in for some time and I've forgotten
how.
Anyone got some new old stock RAM for a 1953 biological computer?
You can't get the parts you know!
Roger Holmes.
|
|
From: James W. <ja...@fr...> - 2007-01-30 18:14:04
|
Roger Holmes wrote:
> Could someone see if they agree with what appears to be
> a memory leak in E3AttributeSet_Inherit. I have a provisional
> fix which is:
>
> In this section of code, change the last but one line
>
>
> // Process the child
> if ( qd3dStatus == kQ3Success )
> {
> // Copy the mask and attributes directly
> resultSet->setData.theMask = childSet->setData.theMask ;
> resultSet->setData.attributes = childSet->setData.attributes ;
> if ( resultSet->setData.attributes.surfaceShader != NULL )
> resultSet->setData.attributes.surfaceShader =
> Q3Shared_GetReference ( childSet->setData.attributes.surfaceShader ) ;
>
>
> to read:
>
> if ( resultSet->setData.attributes.surfaceShader != NULL && result !
> = child )
>
>
> When E3AttributeSet_Inherit gets called with child == result, the
> reference count of surface
> shaders gets incremented incorrectly, which loses huge amounts of
> memory with even
> modest sized textures if you call this routine a lot, which I do when
> doing the CSG
> calculations for windows and doors within walls, which is now done
> for almost every time
> redraw.
>
> If you agree with the change, could you check it in, or remind me how
> to do it
> as I have not done a Quesa check in for some time and I've forgotten
> how.
I didn't know that Q3AttributeSet_Inherit allowed the result to be the
same as the parent or child. It's not documented that way.
It looks to me like that whole section labeled "Process the child" can
be skipped if result == child. Am I wrong?
--
James W. Walker, Innoventive Software LLC
<http://www.frameforge3d.com/>
|
|
From: Roger H. <rog...@mi...> - 2007-01-30 19:04:04
|
On 30 Jan, 2007, at 18:13, James Walker wrote: > > I didn't know that Q3AttributeSet_Inherit allowed the result to be the > same as the parent or child. It's not documented that way. The blue book doesn't say they have to be different. I no longer have the old photocopied documentation from before the blue book. I think some other calls allow the result and inputs to be the same, maybe I'm wrong. > > It looks to me like that whole section labeled "Process the child" can > be skipped if result == child. Am I wrong? I wondered about that too but in my version I opted for minimum change as we are a few weeks from issuing the new version of Interiors which we demoed at MacWorld earlier this month. It seemed to me that section just copied stuff onto itself when child == result. As we don't have any operator= to worry about I think it would be safe to assume that it does what it says without anything happening in the background. Yes, you are right, the whole section can be bypassed under this condition. Roger. |
|
From: James W. W. <os...@jw...> - 2007-01-31 07:26:39
|
On Jan 30, 2007, at 11:03 AM, Roger Holmes wrote: > Yes, you are right, the whole section can be bypassed under this > condition. I've committed that change. |
|
From: Roger H. <rog...@mi...> - 2007-01-31 14:21:25
|
On 31 Jan, 2007, at 07:26, James W. Walker wrote: > I've committed that change. Thank you. I presume the new renderer will be faster than the interactive one, which will be wonderful. I also presume there will be some incompatibilities. Whilst doing the changes, can you try to make a list of what we should look out for, to be published in the release note maybe. Will we get any new facilities at all? I hope this will not affect existing plug-in renderers. In about a month I will have the time to go through the changes Microspot has made to Quesa for our new version and describe what they do and offer them to the Quesa group. IIRC there is something to do with the loading of plug-in renderers in a Macho/Cocoa/Intel environment and one or two fixes for crashes, but most are the result of turning on almost all of XCode's warnings and seeing what it was complaining about - most are just keeping the compiler comfortable but a few things like unitialised variables could lead to real faults. Thanks again, Roger. |
|
From: James W. W. <os...@jw...> - 2007-01-31 17:21:41
|
On Jan 31, 2007, at 6:21 AM, Roger Holmes wrote: > I presume the new renderer will be faster than the interactive one, > which will be wonderful. That's the goal, though I am not far enough along to do benchmarks. I'm also finding a few bugs in the course of going through every aspect of rendering. > I also presume there will be some incompatibilities. Whilst doing the > changes, can you try > to make a list of what we should look out for, to be published in the > release note maybe. OK... the only thing I can think of right now is that there won't be a distinction between the "both" and "flip" backfacing styles, they'll both just use OpenGL two-sided lighting. However there will probably be some differences in what constitutes the "fast path" for trimeshes. > Will we get any new facilities at all? Depends on what you consider a new facility. I'll probably put in a feature of caching a fast-path trimesh as a triangle strip. > I hope this will not affect existing plug-in renderers. No, I don't see why it would. |
