[SoC 2009 - Submitted] Off-screen particles support to Ogre

Threads related to Google Summer of Code
Post Reply
Rosalia
Gnoblar
Posts: 4
Joined: Thu Apr 02, 2009 12:28 am

[SoC 2009 - Submitted] Off-screen particles support to Ogre

Post by Rosalia »

Rosalia Galiazzi Schneider
(rosaliaschneider@gmail.com)

I have just very very sadly lost a big description of my project proposal, because the site asked me to re-login when I submitted. Is there any way someone could recover it? [:(]

User avatar
Assaf Raman
OGRE Team Member
OGRE Team Member
Posts: 3092
Joined: Tue Apr 11, 2006 3:58 pm
Location: TLV, Israel
x 76

Re: [SoC 2009 - Submitted] Off-screen particles support to Ogre

Post by Assaf Raman »

Sorry, no.
Can't you copy the info from the google site?
Watch out for my OGRE related tweets here.

Rosalia
Gnoblar
Posts: 4
Joined: Thu Apr 02, 2009 12:28 am

Re: [SoC 2009 - Submitted] Off-screen particles support to Ogre

Post by Rosalia »

I had it deeply improved. But ok, here it goes again, now with meantime saving :)

The project

The project I want to implement is the eleventh of the suggested ones in the "Help Requested" page. It consists of increasing performance of particle systems in Ogre by rendering most of the particles to a lower resolution offscreen render target. This technique is described in an article ("High-Speed, Off-Screen Particles" by Iain Cantlay, GPU Gems 3) and is claimed to reduce processing overhead without damaging image quality, since most particle systems have low-frequencies and therefore, do not suffer much from downsampling. It is often emphasized in the article, however, that the method parameters must be application-customizable, because the downsampling factor varies with the scene.

Why me?

I'm a fourth-year undergraduate in Computer Science, at Universidade Federal do Rio Grande do Sul (Federal University of Rio Grande do Sul), in Brazil. I've been working with C++ for 2-3 years, and with OpenGL for 1-2 years, besides at least five years experience with C and OpenGL programming, as a hobbyist. I have also been working with Nvidia CG for a couple of months. I'm completely new to Ogre3d, but as I read some tutorials I saw I'm familiar with most concepts, which made me believe that won't be a big hindrance. For some more reasons, my CV and a very under construction portfolio in the following page: www.inf.ufrgs.br/~rgschneider

Schedule

Here a very preliminary schedule, that will most certainly be changed over and over again.

Before 20 April:

- Get to know Ogre3d, usage and source code, aiming specially particle systems
- Study necessary shading language
- Establish a better schedule

20 April - 23 May:

- Continue studying Ogre3d
- Continue studying necessary shading language
- Establish a definitive schedule, by exchanging knowledge and experience with mentors

- Create multiple scenes with particle systems at Ogre3d, for future comparison and testing

23 May - 6 June:

Week 1-2: "Offscreen Depth Testing". This part is conceptually straightforward, however, I believe most language-technology-API issues are probably going to appear in this stage. I still don't know how to validate this without the rest of the code, but ideas will follow.

Week 3-5: "Alpha Blending, Edge Detection and Composing". Once the first part is done, this is not supposed to be too hard. It will be validated within this two weeks.

Week 6: "Validation of the first part". Testing, improving, comparing performance, fixing bugs, writing documentation, cleaning-up code and everything else to make a beautifully presented first part.

13 June - 10 August:

Week 1-2: "Improving". Implement new ideas. For example, after reading the article I thought of a different edge detection, using depth buffer instead of color buffer. This and other improvements will be implemented here. Ogre integration will also fit here.

Week 3: "Validation". Test usage from within Ogre, add customizable parameters, improve usability, complete documentation, clean-up code and test exhaustively, including with help of other, more experienced Ogre users.

10 August - 17 August:

- Last documentation review


I see this is not a exceptional proposal, however it is much better than the one I submitted two days ago (even though not as good as the one I submitted two hours ago) and I believe it can continue to improve exponentially in the next two weeks, with help of users suggestions and knowledge exchange. I am anxiously waiting to discuss the implementation and other more specific technical stuff.

User avatar
tuan kuranes
OGRE Retired Moderator
OGRE Retired Moderator
Posts: 2653
Joined: Wed Sep 24, 2003 8:07 am
Location: Haute Garonne, France
x 4
Contact:

Re: [SoC 2009 - Submitted] Off-screen particles support to Ogre

Post by tuan kuranes »

- For now the planning is very theoretical and not Ogre related ? Can you try to get more into Ogre, and see if you can make a preliminary design&planning accordingly to that ? What parts of Ogre will be impacted, how ?
- Can you give more precision about shader experience ?
- Any possibilities the work might be too light for a complete Gsoc ? add some scenarios demos, general particles optimization, dx10/gl3 ?
- What minimum requirements you're planning ?
- did you checked OOgst Volumetrics demo and source ? What will you bring to ogre more than that ?
- Any other papers, implementations you might want to take example/features of ?

Rosalia
Gnoblar
Posts: 4
Joined: Thu Apr 02, 2009 12:28 am

Re: [SoC 2009 - Submitted] Off-screen particles support to Ogre

Post by Rosalia »

Hi,

So, as I mentioned, I'm completely new to Ogre, but I'm working hard to learn it as quickly as possible. From what I understood, particle systems are created by Ogre users using high-level programming (or high-level scripts). At some point of the pipeline, this will have to be translated into a shader program, and this is where I will implement the modifications (this will become more specific in next days). Some more parameters will also be needed (a default can be set when not provided, for the sake of compatibility with older versions), since there's no parameter that is always adequate.

About my shading experience, I've been working mainly with Nvidia Cg + OpenGL. I have implemented the following techniques: Phong shading, reflection, refraction, fresnel effect, bump mapping, a simple 2d particle system and some more not too advanced stuff. As a last project, I developed bidimensional metaballs (http://en.wikipedia.org/wiki/Metaballs). I can provide the current source code for all these, but I'm cleaning it up to add it to my portfolio, so I'd preferably provide a link within the next 3-4 days. I have also "had contact" with some GLSL, but I never coded it myself till now.

The next two items you pointed, I think they stand a little bit together. To be honest, yes, I do think the project is a little bit more than perfectly achievable. What I already setted in my schedule, however, can be seen as "minimum requirements" you mentioned, as I do not see not finishing this part as a possibility. I was really happy to read your suggestions, since I want to make the schedule better as quickly as possible, but I did not fully understand what you meant. Scenarios demos, if I understand correctly, was something I already kind of predicted as a part of validating and adding documentation (though, of course, there's no way you could have known that :)). General particles optimizing is not quite the point of the article, since the technique would cause great loss of image quality in high-frequency stuff. It is definitely something be thought of, but I believe it would be something more "from scratch" than a addition. Dx 10/gl 3, I don't see what you mean. I didn't go far enough to see whether Ogre provides support for HLSL, GLSL and CG also as a transparent-to-user-shader, if so, however, the specific translations can also be provided.

I just read Ogst Volumetrics post (not to full extent), and from what I understood, the scope is rather different. He does something to improve the quality of the image generated, what I'm proposing aims at very best to keep the quality, while improving performance. I think putting both methods together may be a good idea of improval, but the way to do this didn't jump out of the post directly, so I'd have to do some more research in order to be more specific.

I didn't read, till now, any other papers. Most probable candidates are papers which describe sub-sections of my algorithm, for example, better ways to detect edges, or to render soft particles. If anyone has anything to add as a reference, I'll be glad to hear from it. I just had at Ogst's post about Crytek stuuf on soft particles, I guess this is what I'll be looking next.

Rosalia
Gnoblar
Posts: 4
Joined: Thu Apr 02, 2009 12:28 am

Re: [SoC 2009 - Submitted] Off-screen particles support to Ogre

Post by Rosalia »

Hi,

I've been searching in Ogre Source code for the part that "translates" high level descriptions of particle systems into shaders, but I'm a little bit out of direction. Was it a wring guess on how this is done? Can anyone give me some direction on that?

My experience in Computer Graphics will follow, I'm just a little out of time in the moment.

Regards,
Rosália

User avatar
sinbad
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 19265
Joined: Sun Oct 06, 2002 11:19 pm
Location: Guernsey, Channel Islands
x 66
Contact:

Re: [SoC 2009 - Submitted] Off-screen particles support to Ogre

Post by sinbad »

The particle scripts actually just define the structure of the particle systems, ie the number of particles, how they're emitted, the motion etc. When it comes to rendering, this is delegated to the ParticleSytemRenderer class, of which right now there's only BillboardParticleRenderer. That handles the 'material' directive in the particle scripts, connecting the particles to the on-screen material that they use by name.

The material definition is like any other material definition in Ogre, and can reference shaders (or not). You find the materials in .material scripts, which themselves can reference shaders in .program files (which in turn reference shader source such as .cg, .hlsl or .glsl).

Post Reply