Page 1 of 2
[GSoC 2011] More ideas by the community
Posted: Tue Mar 22, 2011 6:44 pm
by Assaf Raman
I want to start a thread where community members can post ideas for projects.
Students - feel free to pick up ideas from here.
Re: [2011] More ideas by the community
Posted: Tue Mar 22, 2011 6:48 pm
by Assaf Raman
Idea:
SWIG wrapper for OGRE.
SWIG is a software development tool that connects programs written in C and C++ with a variety of high-level programming languages. SWIG is used with different types of target languages including common scripting languages such as Perl, PHP, Python, Tcl and Ruby. The list of supported languages also includes non-scripting languages such as C#, Common Lisp (CLISP, Allegro CL, CFFI, UFFI), D, Go language, Java, Lua, Modula-3, OCAML, Octave and R. Also several interpreted and compiled Scheme implementations (Guile, MzScheme/Racket, Chicken) are supported. SWIG is most commonly used to create high-level interpreted or compiled programming environments, user interfaces, and as a tool for testing and prototyping C/C++ software. SWIG is typically used to parse C/C++ interfaces and generate the 'glue code' required for the above target languages to call into the C/C++ code. SWIG can also export its parse tree in the form of XML and Lisp s-expressions. SWIG is free software and the code that SWIG generates is compatible with both commercial and non-commercial projects.
The project will include writing Interface files for all relevant core OGRE h files, adding a build option to create the wrapper to the OGRE CMake files, and creating a test project in a different language then c++ that test the result wrapper.
Feel free to say good or bad things about this idea.
Re: [2011] More ideas by the community
Posted: Tue Mar 22, 2011 7:03 pm
by Assaf Raman
Searching the forum suggest that SWIG doesn't handle c++ well
http://www.ogre3d.org/forums/viewtopic. ... IG#p419265
I don't have personal experience with it.
Re: [2011] More ideas by the community
Posted: Tue Mar 22, 2011 7:06 pm
by jacmoe
IDEA:
Improve the Resource Manager so that it is able to handle duplicate resource identifiers - mainly by not using the file system name, but instead map it using GUIDs (or similar).
I am aware that Praetor and his team/company has implemented such functionality.
I'll try and dig up some resources on this.
Work on the background loading / streaming.
And some other stuff.
I think that improved resource management would be a huge win for Ogre.
And I hope that one of you candidates are willing to take the idea and turn it into a irresistible GSoC project.
Chris Jones wrote:I like this idea too.
Further thoughts to discuss:
Separate out resource code into a separate component (such as a discussion earlier about splitting ogre up)?
Change how resource groups are handled? I've never really liked resource groups or how they are really embedded into Ogre. I'd like to see it easier to integrate into other libraries/tools resource management.
Re: [2011] More ideas by the community
Posted: Tue Mar 22, 2011 7:08 pm
by jacmoe
Look in the Feature Request forum - I am working on a hand-written C wrapper for Ogre.
A SWIG wrapper would be nice, though. Maybe SWIG 2 is ready for it?
Re: [2011] More ideas by the community
Posted: Tue Mar 22, 2011 7:19 pm
by Assaf Raman
Idea: Some HW instancing work:
1. Create a good normal HW instancing sample based on one of MS instancing samples and see that it works correctly with GL, D3D9 and D3D11 render systems.
1. Translate
Path Instancing to a new OGRE sample.
Re: [2011] More ideas by the community
Posted: Tue Mar 22, 2011 7:22 pm
by Assaf Raman
jacmoe wrote:
Look in the Feature Request forum - I am working on a hand-written C wrapper for Ogre.
A SWIG wrapper would be nice, though. Maybe SWIG 2 is ready for it?
I don't mind if the SWIG wrapper will wrap your C wrapper.
BTW: What about a student helping you out with the C wrapper?
Re: [2011] More ideas by the community
Posted: Tue Mar 22, 2011 8:09 pm
by elie
What about the proposal for GSoC 2008 regarding a material/shader library that was not accepted?
http://www.ogre3d.org/forums/viewtopic.php?f=13&t=40281
Re: [2011] More ideas by the community
Posted: Tue Mar 22, 2011 8:26 pm
by andrei_radu
Searching the forum suggest that SWIG doesn't handle c++ well
viewtopic.php?f=3&t=63153&p=419265&hilit=SWIG#p419265
I don't have personal experience with it.
I know that crystalspace uses SWIG, and it's written in C++, so it's definitely possible(from what I know, it's used quite often for CS).
Re: [2011] More ideas by the community
Posted: Tue Mar 22, 2011 8:28 pm
by Assaf Raman
Lots of what he suggested was implemented since then as part as the RTSS.
So - any project of this type will be "extending the RTSS" in some way.
I will love to see some new ideas for extending the RTSS.
Re: [2011] More ideas by the community
Posted: Tue Mar 22, 2011 8:31 pm
by Assaf Raman
andrei_radu wrote:
Searching the forum suggest that SWIG doesn't handle c++ well
viewtopic.php?f=3&t=63153&p=419265&hilit=SWIG#p419265
I don't have personal experience with it.
I know that crystalspace uses SWIG, and it's written in C++, so it's definitely possible(from what I know, it's used quite often for CS).
Any student that wants this idea will have to show a small sample that wraps one existing OGRE class with SWIG as a proof of concept.
This type of project can really move OGRE forward - if it is technically possible.
Re: [2011] More ideas by the community
Posted: Tue Mar 22, 2011 11:44 pm
by Noman
IDEA : Integrate Deferred Rendering pipeline with the Run-Time-Shader-Generator (RTSS)
Currently, the deferred rendering demo uses a simple shader generator to generate the shaders. This means that besides the basic rendering options, not much is supported.
The RTSS can generate shaders that take care of all of the fixed pipeline, but only generates them for the forward rendering method.
It should be possible to use it (or refactor it) to split different stages (lighting / transforms etc) that already exist in the system differently between shaders, generating shaders that render objects to the G-buffer automatically. A similar process can be used to generate shaders that render light sources from the G-buffer, giving Ogre a true deferred pipeline for the entire fixed-function set of materials.
Re: [2011] More ideas by the community
Posted: Wed Mar 23, 2011 4:35 am
by cin
Add point light shadows in OGRE. And add it to Deferred Shading demo too.
Re: [2011] More ideas by the community
Posted: Wed Mar 23, 2011 8:44 am
by tuan kuranes
- A GPUGPU compute abstract plugin
GPUGPU Plugin with an
Opencl pluginn
Cuda plugin, and directcompute plugin instance
- Render Command Buffers (even phones are multicore now)
http://www.gamebryo.com/GameFest2008 +
http://beautifulpixels.blogspot.com/200 ... mmand.html (From other engines (unity,unigine,frostbite), still useful even with dx11 own version of command buffers)
- Data Orientation Design : rework culling, renderqueue, transformations, etc... =>
http://www.slideshare.net/search/slides ... from=basic
(a good first step toward better multicore/multithread task oriented engine as DOD code is much easier to parallelise)
- Improve shadows and shadow demo (like
intel shadow explorer) with latest techniques ,
Normal Offset Shadows ,
SDSM ,
Adaptive Volumetric Shadow Maps
Re: [2011] More ideas by the community
Posted: Wed Mar 23, 2011 8:49 am
by boyamer
Agree with Noman,
Deferred rendering pipeline with the RTSS would be very nice, automatic generate the shader stuff for geometry rendered to G-Buffer, handle even skinned mesh,
with alpha support (maybe taking look at:
http://null-ptr.blogspot.com/2009/01/de ... nding.html).
Another idea would be to improve the DirectX 11 render system by adding Hull, Tesselate and compute shaders.
Thanks,
Amer
Re: [2011] More ideas by the community
Posted: Wed Mar 23, 2011 9:06 am
by Assaf Raman
@tuan kuranes: Can explain more why do you think GPUGPU should be a part of OGRE?
Re: [2011] More ideas by the community
Posted: Wed Mar 23, 2011 10:03 am
by tuan kuranes
@Assaf Raman : GpuGpu gives access to use of GPU that shader doesn't, and having it integrated in Ogre would ease the bridging/sharing of data (texture/memory) between shaders and gpugpu code. Many post-processing algorithms are moving to pure gpugpu code, therefore at some point not that far, compositor will be useless if they're not supporting it.
Ogre does abstract render systems, why it should not do the same for compute shaders ?
http://unigine.blogspot.com/2010/02/cud ... rt-ii.html
http://www.idevgames.com/forums/thread-8649.html
http://www.nvidia.com/content/GTC/docum ... _GTC09.pdf
Re: [2011] More ideas by the community
Posted: Wed Mar 23, 2011 10:11 am
by Assaf Raman
@tuan kuranes: I think that GPGPU is beyond the scope of OGRE core. The only thing relevant in the core may be code to ease the bridging/sharing of data with GPGPU - if that is missing.
Re: [2011] More ideas by the community
Posted: Wed Mar 23, 2011 11:54 am
by tuan kuranes
@Assaf Raman : Ogre will not allow users to use directcompute shaders in compositor then ?
Re: [2011] More ideas by the community
Posted: Wed Mar 23, 2011 11:59 am
by Assaf Raman
@tuan kuranes: Sorry, I guess I am missing something - what keeps you from using directcompute shaders in compositor even today?
Re: [2011] More ideas by the community
Posted: Wed Mar 23, 2011 12:07 pm
by tuan kuranes
@Assaf Raman : Consistency. The fact that other rendersystem (OpenGL, opengl ES) doesn't have any equivalence and therefore makes it a single rendersytem only feature ?
Re: [2011] More ideas by the community
Posted: Wed Mar 23, 2011 7:49 pm
by Jabberwocky
If this would help to significantly reduce Ogre's batch-rendering CPU bottleneck, I'm a huge fan of this proposal.
tuan kuranes wrote:
- Data Orientation Design : rework culling, renderqueue, transformations, etc... =>
http://www.slideshare.net/search/slides ... from=basic
(a good first step toward better multicore/multithread task oriented engine as DOD code is much easier to parallelise)
Ditto.
Re: [2011] More ideas by the community
Posted: Thu Mar 24, 2011 4:29 am
by th3flyboy
tuan kuranes wrote:@Assaf Raman : Consistency. The fact that other rendersystem (OpenGL, opengl ES) doesn't have any equivalence and therefore makes it a single rendersytem only feature ?
Actually, there is an equivalent handled by the same standards group as OpenGL, OpenCL
http://www.khronos.org/opencl/.
Re: [2011] More ideas by the community
Posted: Thu Mar 24, 2011 10:27 am
by Assaf Raman
Idea: serialize OGRE resources using
google protocol buffers - it is the best standardized binary format I know, and will enable editing of OGRE resources in other languages then c++.
Re: [2011] More ideas by the community
Posted: Fri Mar 25, 2011 10:26 am
by SunSailor
Assaf Raman wrote:Idea: serialize OGRE resources using
google protocol buffers - it is the best standardized binary format I know, and will enable editing of OGRE resources in other languages then c++.
Yes, had a similar idea and this post points in the same direction. Serialization is very inconsistent and feels plugged into the system. I would suggest a full serialization layer to OGRE, which would allow to serialize a whole scene from and to file, especially meshes, materials and animations. Some kind of reference mechanism would be needed and a filter to enable and disable object types and it should be possible to start serialization from certain points in the hierachy.
I think most, if not all, open source engines lack of such a mechanism, which would allow to export a whole animated scene out of an editor into the engine. The benefit of such generic mechanism would be, that not a dedicated framework would be needed to achieve this, although the freedom to extend the description format remains.