Shoggoth release planning
- sinbad
- OGRE Retired Team Member
- Posts: 19269
- Joined: Sun Oct 06, 2002 11:19 pm
- Location: Guernsey, Channel Islands
- x 66
- Contact:
Shoggoth release planning
Ok, I think it's time to start planning getting Shoggoth to stage where it can become the stable version - this means tidying up a few loose ends, bumping anything that's not realistically going to get done to the next version, etc. That's because it's approaching a year since the last stable, and there's lots of features in HEAD which are useful and really stable enough for people to start using. Here's my thoughts.
Things that need to be finished
- Manual update to cover new script compilers
- Better error reporting on new script compilers; this includes:
-- reporting invalid / unhandled directives (they're ignored right now it seems)
-- more specific error messages where possible, not just 'invalid params' with a line number
- Testing new GLX subsystem (patch)
Things that could be frozen in their current state
- Any resource loading enhancements not finished yet, so long as current features are consistent
Things that can evolve after the 1.6.0 release
- DirectX10 - I don't think this will be stable enough by then, plus we will want to introduce more core interface changes once the base functionality is there (for SM4 features and other things) - so it would probably be best to have a stable API freeze before then
- Everything else that's not done by the time we freeze the codebase can go into the next version.
I'd like to aim for the end of April for RC1 (at which point the v1-6 branch will be created), with the full 1.6 release around the end of May. How does that sound?
Things that need to be finished
- Manual update to cover new script compilers
- Better error reporting on new script compilers; this includes:
-- reporting invalid / unhandled directives (they're ignored right now it seems)
-- more specific error messages where possible, not just 'invalid params' with a line number
- Testing new GLX subsystem (patch)
Things that could be frozen in their current state
- Any resource loading enhancements not finished yet, so long as current features are consistent
Things that can evolve after the 1.6.0 release
- DirectX10 - I don't think this will be stable enough by then, plus we will want to introduce more core interface changes once the base functionality is there (for SM4 features and other things) - so it would probably be best to have a stable API freeze before then
- Everything else that's not done by the time we freeze the codebase can go into the next version.
I'd like to aim for the end of April for RC1 (at which point the v1-6 branch will be created), with the full 1.6 release around the end of May. How does that sound?
- Assaf Raman
- OGRE Team Member
- Posts: 3092
- Joined: Tue Apr 11, 2006 3:58 pm
- Location: TLV, Israel
- x 76
Well, we can give the DX10 in its current state as a preview.
Watch out for my OGRE related tweets here.
- PolyVox
- OGRE Contributor
- Posts: 1316
- Joined: Tue Nov 21, 2006 11:28 am
- Location: Groningen, The Netherlands
- x 18
- Contact:
I have no real expertise here, but I would imagine it was worth waiting for the DirectX 10 render system to become more mature. As I see it the implementation of the DirectX 10 render system may well require a lot of interface breaking changes. If the interface is frozen then development can probably only continue in cvs head and Shoggoth could be stuck with a half-implemented DirectX 10 render system.
As I understand it a lot could change for version 2.0 (scene manager redesign) and so will probably be at least another year. That's a long time to wait for a DirectX 10 renderer...
Just my thoughts
As I understand it a lot could change for version 2.0 (scene manager redesign) and so will probably be at least another year. That's a long time to wait for a DirectX 10 renderer...
Just my thoughts
- Assaf Raman
- OGRE Team Member
- Posts: 3092
- Joined: Tue Apr 11, 2006 3:58 pm
- Location: TLV, Israel
- x 76
Well, anyone will be able to get it from the CVS I guess.
Watch out for my OGRE related tweets here.
- Evak
- Orc Shaman
- Posts: 707
- Joined: Sun Apr 02, 2006 7:51 pm
- Location: Sacramento, CA
- x 1
- Contact:
Most people still don't have Vista let alone a DX10 card, probably less than 10% can actually use the DX10 renderer. So I don't think that should hold back the release of shoggoth. Not forgetting that there's also Mac and Linux developers that will never make use of DX10 regardless.
I am following Assaf Ramans DX10 progress thread and like keeping track of his progress , hope that by the time the DX10 render system is mature, a more significant chunk of developers will have migrated to Vista and DX10.
I am following Assaf Ramans DX10 progress thread and like keeping track of his progress , hope that by the time the DX10 render system is mature, a more significant chunk of developers will have migrated to Vista and DX10.
- DWORD
- OGRE Retired Moderator
- Posts: 1365
- Joined: Tue Sep 07, 2004 12:43 pm
- Location: Aalborg, Denmark
- Contact:
- Assaf Raman
- OGRE Team Member
- Posts: 3092
- Joined: Tue Apr 11, 2006 3:58 pm
- Location: TLV, Israel
- x 76
We can release shoggoth without the DX10 and have a separate download of the DX10 system as pre-release version – with an appropriate warning, this way – we won't stop anyone but keep the main download without unstable code.
Watch out for my OGRE related tweets here.
- Wolfmanfx
- OGRE Team Member
- Posts: 1525
- Joined: Fri Feb 03, 2006 10:37 pm
- Location: Austria - Leoben
- x 99
- Contact:
- DWORD
- OGRE Retired Moderator
- Posts: 1365
- Joined: Tue Sep 07, 2004 12:43 pm
- Location: Aalborg, Denmark
- Contact:
@Assaf Raman:
I didn't mean not to have the DX10 render system in 1.6, I hope it didn't sound like that. But from my understanding the current implementation of it is using the existing render system interface, and includes only the features that are already in the old render systems. Am I wrong about this?
So what I meant is, I think it's a good idea to include a working version of the DX10 render system that complies with the existing interface in 1.6. Then the changes to Ogre's core code that are necessary to implement all the new fancy features of DX10 could go in the next unstable branch, 1.7?.
I didn't mean not to have the DX10 render system in 1.6, I hope it didn't sound like that. But from my understanding the current implementation of it is using the existing render system interface, and includes only the features that are already in the old render systems. Am I wrong about this?
So what I meant is, I think it's a good idea to include a working version of the DX10 render system that complies with the existing interface in 1.6. Then the changes to Ogre's core code that are necessary to implement all the new fancy features of DX10 could go in the next unstable branch, 1.7?.
- syedhs
- Silver Sponsor
- Posts: 2703
- Joined: Mon Aug 29, 2005 3:24 pm
- Location: Kuala Lumpur, Malaysia
- x 51
DX10 can be released separately if DX10 plugin is self-contained. What I mean is if there are changes in Ogre needed so that DX10 can be released, then too bad we have to wait until 2.0.
A willow deeply scarred, somebody's broken heart
And a washed-out dream
They follow the pattern of the wind, ya' see
Cause they got no place to be
That's why I'm starting with me
And a washed-out dream
They follow the pattern of the wind, ya' see
Cause they got no place to be
That's why I'm starting with me
- Assaf Raman
- OGRE Team Member
- Posts: 3092
- Joined: Tue Apr 11, 2006 3:58 pm
- Location: TLV, Israel
- x 76
Talk to me about it on this thread and I will help you:Wolfmanfx wrote:With the DX10 i got some material problems it gave me Exceptions that a shader is not supported (or is there a way to turn this off).
http://www.ogre3d.org/phpBB2/viewtopic.php?t=36493
The only main thing is the ShadowVolumeExtrudeProgram (a class containing source for vertex programs for extruding shadow volumes), there are hard coded assembly shaders in the OgreShadowVolumeExtrudeProgram.cpp, assembly shaders are not supported in DX10, so, we have a problem…syedhs wrote:...is if there are changes in Ogre needed so that DX10 can be released...
Watch out for my OGRE related tweets here.
- sparkprime
- Ogre Magi
- Posts: 1137
- Joined: Mon May 07, 2007 3:43 am
- Location: Ossining, New York
- x 13
- Contact:
- PolyVox
- OGRE Contributor
- Posts: 1316
- Joined: Tue Nov 21, 2006 11:28 am
- Location: Groningen, The Netherlands
- x 18
- Contact:
I'm guessing it's this thread:sparkprime wrote:What are the resource loading enhancements sinbad mentioned?
http://www.ogre3d.org/phpBB2/viewtopic.php?t=38078
- sinbad
- OGRE Retired Team Member
- Posts: 19269
- Joined: Sun Oct 06, 2002 11:19 pm
- Location: Guernsey, Channel Islands
- x 66
- Contact:
Yes, whatever the state of Dx10 at the point we branch the code will be the 'preview' code for 1.6. I don't want to wait for it to be finished before 1.6 because:
a) there's still quite a lot to do
b) we will definitely need to change the core API to accommodate at least the new SM4 features, and perhaps also to play nicer with things Dx10 makes a fuss about, like state blocks and input assembly / shader matching.
Obviously anyone wanting to get the latest Dx10 code after 1.6 can get from CVS. Thus it would be nice to have a 'frozen' API before these changes and also to push out all the features that have been developed over the last year as a stable version. Having had a stable released will also free up HEAD development a little more too (since more people will be able to move onto stable again), allowing a bit more experimentation, which will help things like Dx10 in the long run, and also whatever comes out of Summer of Code this year.
I also think there will be an Ogre 1.8 rather than jumping straight to 2.0, which can include the final Dx10 code including any necessary core API changes. I had lots of ideas for 2.0 but that was when I was hoping to have more work time to spend on such major changes. The way business has gone over the last year has forced me to rethink how much time I can spend on Ogre and thus my v2.0 plans. So more gradual evolution including a v1.8 is more likely.
a) there's still quite a lot to do
b) we will definitely need to change the core API to accommodate at least the new SM4 features, and perhaps also to play nicer with things Dx10 makes a fuss about, like state blocks and input assembly / shader matching.
Obviously anyone wanting to get the latest Dx10 code after 1.6 can get from CVS. Thus it would be nice to have a 'frozen' API before these changes and also to push out all the features that have been developed over the last year as a stable version. Having had a stable released will also free up HEAD development a little more too (since more people will be able to move onto stable again), allowing a bit more experimentation, which will help things like Dx10 in the long run, and also whatever comes out of Summer of Code this year.
I also think there will be an Ogre 1.8 rather than jumping straight to 2.0, which can include the final Dx10 code including any necessary core API changes. I had lots of ideas for 2.0 but that was when I was hoping to have more work time to spend on such major changes. The way business has gone over the last year has forced me to rethink how much time I can spend on Ogre and thus my v2.0 plans. So more gradual evolution including a v1.8 is more likely.
- Praetor
- OGRE Retired Team Member
- Posts: 3335
- Joined: Tue Jun 21, 2005 8:26 pm
- Location: Rochester, New York, US
- x 3
- Contact:
I've committed already a changed which causes an error to be thrown when an unhandled script directive is encountered. I also added support for more detailed messages. I've started going through the translators now to add these. They should be really really helpful when writing materials.
As for the enhancement to resource management. I've encountered no problems or needed any new features on this front so far. Please please please if someone has anything speak up now, or else the interfaces that are there now will be what's in Shoggoth.
As for the enhancement to resource management. I've encountered no problems or needed any new features on this front so far. Please please please if someone has anything speak up now, or else the interfaces that are there now will be what's in Shoggoth.
- Klaim
- Old One
- Posts: 2565
- Joined: Sun Sep 11, 2005 1:04 am
- Location: Paris, France
- x 56
- Contact:
- syedhs
- Silver Sponsor
- Posts: 2703
- Joined: Mon Aug 29, 2005 3:24 pm
- Location: Kuala Lumpur, Malaysia
- x 51
I would love the muti-threading patch (or rather enhancement) by Sparkprime can be integrated into Shoggoth - unfortunately, I have not yet find time to test it (excuse, excuse).
A willow deeply scarred, somebody's broken heart
And a washed-out dream
They follow the pattern of the wind, ya' see
Cause they got no place to be
That's why I'm starting with me
And a washed-out dream
They follow the pattern of the wind, ya' see
Cause they got no place to be
That's why I'm starting with me
- sparkprime
- Ogre Magi
- Posts: 1137
- Joined: Mon May 07, 2007 3:43 am
- Location: Ossining, New York
- x 13
- Contact:
i get back to england tonight
i'll work all day sunday on filling the gaps in that patch, and if i can, compile all the demos in {static,dynamic}{unthreaded,semithread,threaded} versions (i.e. 6 copies of each)
this seems to be a pain in vs9 so i may need to make some script that autogenerates vcproj files
any suggestions about how to do this without writing a script are welcome
i'll work all day sunday on filling the gaps in that patch, and if i can, compile all the demos in {static,dynamic}{unthreaded,semithread,threaded} versions (i.e. 6 copies of each)
this seems to be a pain in vs9 so i may need to make some script that autogenerates vcproj files
any suggestions about how to do this without writing a script are welcome
- sinbad
- OGRE Retired Team Member
- Posts: 19269
- Joined: Sun Oct 06, 2002 11:19 pm
- Location: Guernsey, Channel Islands
- x 66
- Contact:
Excellent, thanks. Could you sum up the new features of the new script compilers sometime too please? I don't mind writing the manual updates but I want to make sure I include everything accurately, and I know things developed incrementally. Just a bullet list or a bunch of links / pointers would be fine.Praetor wrote:I've committed already a changed which causes an error to be thrown when an unhandled script directive is encountered. I also added support for more detailed messages. I've started going through the translators now to add these. They should be really really helpful when writing materials.
As for the enhancement to resource management. I've encountered no problems or needed any new features on this front so far. Please please please if someone has anything speak up now, or else the interfaces that are there now will be what's in Shoggoth.
- Praetor
- OGRE Retired Team Member
- Posts: 3335
- Joined: Tue Jun 21, 2005 8:26 pm
- Location: Rochester, New York, US
- x 3
- Contact:
- spookyboo
- Silver Sponsor
- Posts: 1141
- Joined: Tue Jul 06, 2004 5:57 am
- x 151
- Contact:
- sinbad
- OGRE Retired Team Member
- Posts: 19269
- Joined: Sun Oct 06, 2002 11:19 pm
- Location: Guernsey, Channel Islands
- x 66
- Contact:
Yeah, that would be great - we can also refer to it from the Shoggoth notes as a quick reference.Praetor wrote:Would a wiki article be best? You can just pull from that for the manual?
Yes, it's there because you can fall back on the old compilers with a define (Compositor used it).Does the Compiler2Pass still exist in Shoggoth? I want to migrate to the new scriptcompiler after Shoggoth comes out, but don't want to be confronted immediatly with a major interface break.
- Praetor
- OGRE Retired Team Member
- Posts: 3335
- Joined: Tue Jun 21, 2005 8:26 pm
- Location: Rochester, New York, US
- x 3
- Contact:
- SunSailor
- Gnoll
- Posts: 699
- Joined: Sun Jan 02, 2005 5:45 pm
- Location: Velbert, Germany
- x 2
- Contact: