Planning for OpenSG 2
This page contains discussion for open issues concerning OpenSG 2 (both Beta and Release). For a review of the motivation behind and vision for version 2, please see wiki:OpenSG2Vision. For a generic high-level roadmap, please see wiki:OpenSG2Roadmap.
If you have an issue with OpenSG 2, you can add it here. However, if it is a minor issue or something that doesn't need discussion because it is very concrete or it has been discussed and agreed on on the mailing list and the solution is clear, please just add a ticket.
Over time all the discussions on this page should be turned into tickets and then disappear as they are fixed.
How to help: you can help OpenSG in many ways including...
- Add new ideas for additional capabilites and features. Do you have a feature you have always wanted? If you do, let us know but be warned we may ask you to help add it. :)
- Read and contribute to the on-going discussions. We want everyone to participate so we can generate more ideas and make sure we solve the problems in a way that will work for everyone.
- Download the in-development code and try it out. If you have problems let us know, if you have ideas let us know, and if it works perfectly and solves all your problems then definitely let us know.
Issues with longer discussions
These are issues with longer discussions on separate pages:
|Building||The new build and all the issues related to it|
|Dev/FeaturesToPortFrom1to2||Discussion and list of all the things yet to port from the 1.x build|
|Pointers||2.0 has a new pointer system that needs to be finalized and decided upon. This is a *big* discussion|
|FileIO||Ideas and discussions about file io changes for 2.0. (formats, network loading, etc)|
|Plugins & Pathes||We are considering a more general plugin system for 2.0. This is the area to discuss and decide how to do it.|
|GL Id handling||How should we handle GL Id assignment in OpenSG.|
|Examples/Demos/Tutorials||We need demos and examples but we have to decided what and how to include them.|
|Multi-frame Data||There is no well-defined way to store data that is used for multiple frames yet|
Currently OpenSG strictly follows the OpenGL base specs for extension handling. Which has advantages, as it allows to compile against OpenGL 1.0 headers and run on systems with OpenGL 1.0. The current system also supports context-specific extension functions, which are officially mandated for Windows. The downside is that all code has to be written with the thought in mind that any extension might not be available, and that it can be a little painful to access the extension functions, as they need to be registered with and accessed through the dox:Window.
The two aspects are somewhat independent.
The pain of having to access the functions through the Window can be alleviated through the use of a generic extension wrangler like GLEW or GLEE. GLEE is a little nicer to use as it doesn't need any initialization (all done lazy), but GLEW can support multiple contexts (although using that is not quite trivial and will require some noticeable changes).
The other problem can be addressed by simply requiring a certain version of OpenGL, e.g. 2.0, and expecting all the extensions that have been rolled into that as a basis.
DR: I agree that the current examples in the code are painful, but I think the main pain is not having predefined types for the function pointers. I didn't want to depend on them being there, and I didn't want to replicate all of them, but the current way is just painful. I think we can just copy the ones from the official OpenGL headers and change the namespace to significantly simplify the extension handling. I'm a little weary about using GLEW or GLEE, as that might get us into serious trouble on Windows later.
Concerning requiring OpenGL 2: Yes, there are only very few platforms that don't support it these days, but new platforms are emerging (OpenGL ES), and requiring some serious extensions might make this complicated. There are also still some people that use older system that do not support it... I'm not too sure what he real benefit is except some slightly simpler code. Most current code just fails when the extension isn't there, which IMHO is acceptable behavior, as long as an error message is printed, so the real overhead of supporting missing extensions is not that big.
Member / Argument Naming
Some newer parts use the typed naming convention (_szName for members, UInt32 uArg for arguments etc.).
I don't like it very much. IMHO it doesn't add anything but makes it hard to change types and clutters up the code. --DR
I don't think it makes sense either. See Joel Spolsky's article on the question (read it until the end, I realize it's quite long). --Akos
This is our chance to get rid of bad/wrong/confusing names. For things that are just renaming I would keep the old version around in a COMPAT_1 block, with a depreciation warning. What should we rename?
|Old Name||New Name||Reason|
|Geometry Properties||Geometry Attributes||Closer to OpenGL standard|
This is the area to add short descriptions or links to longer discussions about any ideas you have for OpenSG 2.0. We may not have the time or skill to do all of them for this release, but we would love to hear ideas from the entire community no matter how small or large. No idea is too insignificant or outlandish. So let the ideas flow....
Note: As more ideas are contributed feel free to re-arrange this area as needed to categorize related topics
- Make the render traversal more extensible
Compact list: #6, #10, #16, #33, #37, #40, #41, #48, #51, #55, #57, #59, #60, #61, #76, #79, #83, #86, #88, #92, #93, #96, #99, #110, #127, #132, #140, #143, #166, #167, #171, #177, #181, #184, #185, #186, #199, #203, #208, #215, #222, #230