Google Summer of Code 2010 - Any advice?

[LucaMoller]

Hello guys!

I was thinking about participating in the Google Summer Of Code this year and that maybe I could do something for Ogre. Last year I've worked on a project of a fighting game (as the main programmer) in which I used Ogre3d and NxOgre. I've never had experiences with 3D (neither physics) engines before working on this game, but I found Ogre amazing and would like very much to contribute developing something if possible.

I took a look at the wiki pages about the ideas for projects, but I'm not sure if they suit me. So I came up with the idea of creating this topic to try to get some help about an idea of project. As I said before, I dont have much experience, so I dont have I clear idea of what I'm capable of doing or not. I would really appreciate talking to a mentor to get some advice and to try to know better what I'm able to do. (To me, Ogre looks like a very advanced project that needs specific knowledge to its development. Maybe it is a bit too hard for me yet, and I should look for something easier to apply for GSoC)


Here are some of my past experiences (everything with C/C++):
- Video of the fighting game: http://www.youtube.com/watch?v=rtF50nlVCCw
- An older video that shows a little better the implemented ragdoll: http://www.youtube.com/watch?v=RkD48e-M ... re=related
- In 2008 I worked on a lan poker with handmade RSA criptography
- I've been training and participating in ACM ICPC for 2 years, since I got in the university (Got to the brazilian finals 2 times, with a bronze medal in the second one =D)

As you can see, I didn't post at all in the Ogre main forum until now (though I have some posts in the NxOgre Addon Forum)...
Thanks in advance for any reply!

[Noman]

Hi!

I'm a two-time GSoC student and there's a good chance of me mentoring, so here is my take :

First of all, believe in yourself. If you don't think that you are good enough for the program, your application will reflect it and you will probably not selected. I'm not saying that you aren't good enough, I'm saying that believing that you are good enough will allow you to demand more from yourself, which will improve your application.

That being said, when writing an application you are essentially pitching two things :
1) Your idea. It might be a bit easier if you choose an idea from the help requested list (or inspired by it), but it is only the beginning of the story. You need to put a lot of effort in the proposal! It is quite easy for us to tell the difference between copy-paste ideas and well-researched ones. In fact, for my 2nd GSoC project, writing the application was about 10-20% of the total time spent on the project, because it involved a large portion of the design phase.
When thinking about an idea, you have to find something that both interests you (so that you will want to put time into researching and making it look good) and is useful to the ogre community. Not an easy task, but definitely possible.

2) Yourself! You seem to have ogre-related experience, which is a plus, but as you said, this is your first post in the main ogre forums. Make us believe that you are part of this community!

Good luck!

[LucaMoller]

I'm trying to come up with my own idea. If I find something I'm more familiar with, I would be much more confident.
Until now, nothing usefull came to my mind, I'll keep on thinking... (If anyone has a good suggestion different from the ones in the HelpRequest list on the wiki, please let me know, even if its not the project idea itself but only an area where something could be done so I could try to dig up something myself)

[stealth977]

Well, first of all, i usually have absurd ideas, so dont take it so serious

And now, 2 ideas;

1 - CODEC based Mesh System accompanies by a new Entity Object (or MovableObject). What i mean by CODEC Based is:
- It will not depend on any FIXED mesh format, it will have a definition of required data and will load and save this data through an abstract serializer class which will perform as a CODEC and which can be registered to a factory, so that this new mesh class can read from and write to any pre-supplied format provided that there is a registered Serializer for it
- Example: SceneManager->createNewEntity("ent1.obj") will load using OBJ_NEWENTITY_SERIALIZER if there is one registered for *.obj
- Example: SceneManager->createNewEntity("ent1.3ds") will load using 3DS_NEWENTITY_SERIALIZER if there is one registered for *.3ds
etc... This way users can even create and use their own custom serializers for their own custom mesh format...What serializer will do is to extract the REQUIRED Data for the new mesh class (its up to the serializer how it will extract this data, if a format doesnt have the data, the serializer for that format may use default values or calculate the data while reading)

2 - OGRE's ResourceManagement system lacks certain features. A new resource management system can be developed which can:
- Identify duplicate resources
- Create resource dependency list reports
- Detection and refreshing of modified resources
- Resolving conflicts of resources shared between resource groups...etc...

Just my 2 cents...

Just a small note on idea 1:
- I can guess that many believe OGRE's current FIXED binary mesh format is optimized and best for rendering bla bla etc.. This may be right, i really dont care.. But lets have a wider perspective, why is there a different format for each engine, why is there different versions of mesh formats for each version of the same engine? Thats because the mesh format is actually project dependent, your fixed format may not satisfy my needs for a particular project...

- Why are there multiple image formats? Why dont we say TGA is the best and the most optimized format for OGRE and lets only support TGA and dont support the rest? Why do we use a CODEC based Ogre::Image which can read from and write to multiple formats? Because its the best solution, let users use whatever image format they like, provided that they all are converted to a COMMON INTERFACE and it can be expanded by adding more codecs.

- So why dont we follow the Ogre::Image case for meshes? If we just turn the mesh class into a COMMON_INTERFACE for any format, just like Ogre::Image, users can expand it to read from and write to any mesh format they see fit, total FREEDOM...

* If you are going to argue that reading from an 3ds file and extracting the data required for an Ogre Common Mesh Data will be slow, extracting/saving a jpeg data is much slower than a tga data, but its not OGRE's problem, its users problem, let the user have options...

[jjp]

Meshes and images are very different from the point of view of a graphics engine. The engine actually works on the mesh data, while images basically "pass through" the engine. So it is natural that there is one mesh format, which suits the graphics engine, while image formats aren't that important to the engine. I don't think your idea makes much sense. If you need your data in another format use whatever you like and then convert it into Ogre's format.

[xadhoom]

Hmm, somehow I don´t see your point jjp.

Image:
- load imagefile into certain buffer (probably uncompress)
- send image data to the GPU
- (the rest is linking the texture handle to passes/compositors etc)

Mesh:
- load meshfile data into certain arrays
- send vertex, normal, texcoord data to the GPU
- (the rest is linking materials/textures etc, to that data)

Ofcourse there are some differences between both resources but why should they influence the serialisation process?
And if I understand Ismail correctly he does not propose to drop the ogre mesh format "just" to change the API for the serialisation...

xad

[stealth977]

jjp: I dont think you understand it.

The data is the COMMON_INTERFACE, it will be just like what OGRE wants. However, the format of the file is none of OGRE's business, it is the READER'S (Serializer) business...

If you make that separation, you can put any pluggable code in between FILE and the DATA and the engine will continue functioning as usual.

Whats the current approach? You start reading the mesh file, you know where the data you are looking for, you seek there, read it, read next etc.. What i am suggesting is, you tell the CustomSerializer to provide you the mesh data you need, you just point it the file to read that data from. Then that custom serializer opens the file and prepares the data OGRE needs thats it, OGRE shouldnt care how data is written there, in what order, what granularity, what resolution etc., the rest works just like current system...

If you do it like that, its possible to write a serializer for any file format in the market, the conversion will be made by the serializer itself, just like Ogre::Image...

[stealth977]

Here are 2 possible scenarios:

Scenario 1: Development:
How many times did you work on a model , convert it to some intermediate format, than convert to OGRE and test in your app, only to find that you need more tweaking and restart the process??

#ifdef PRODUCTION
#define MESHEXTENSION ".mesh"
#else
#define MESHEXTENSION ".mesh.xml"
#endif

in your code:
scenemanager->createNewEntity(EntityName + MESHEXTENSION);

now you dont need to RECONVERT your mesh each time you make any changes. During development, the code will use .mesh.xml format, and the Mesh will use the CODEC for that format to read its required data, and when the product is compiled to ship, it will use ".mesh" format and the data will be read using that format.

Scenario 2:
What if you have an application that streams objects(meshes) over the wire? You would want to have best speed/size ratio possible. If your objects dont need the fractional floats for position / normals / texcoords, you may want to use your own mesh format (maybe same as current ogre mesh format) but the vertex data to be saved as shorts instead of floats.

All you need to do is to create your own plugin and register it as a Mesh CODEC (Serializer), since OGRE will use its interface to read the data it needs, the shorts will be AUTO CONVERTED by the serializer to floats and passed to OGRE, OGRE WONT EVEN NOTICE THE DIFFERENCE, but now you will have 1 / 2 the data to send/receive over the wire...

The examples can be multiplied easily..

[sinbad]

Actually, you can already do what you want to do here - which is basically to externalise the loading of meshes.

If you choose to do this, and personally I would never support lots of random formats in a production 'run time' project because the costs of conversion from those formats is prohibitive when you have any reasonable number of assets (so we're solely talking about editors / content creator projects here), then you can simply drive the Ogre Mesh system entirely procedurally. I've worked on multiple projects that have done this (and they were all editors of some kind), providing all the load/save/import functionality at the application layer and then injecting resource data via ManualLoader implementations.

The only difference between that and what you want to do is that your requested way is reactive - ie you're expecting the mesh load to be triggered passively via a createEntity or similar, and you want to call out to the externalised provider from that, which will then do precisely the same as what the systems I've worked on have done (except they did it proactively, since they were in control of the scene anyway (they're editors) it's actually tidier to do it that way). It all depends on how you design your systems, the ones I've worked on haven't needed the call-out by design to be able to handle lots of different formats, but for systems that did need it, this could probably be an extension to the ResourceLoadingListener (which currently only allows externalisation of the stream).

About meshes being streamed over the wire; well, I've worked on projects like that, and they are also usually building mesh data pro-actively, by nature. The data is streamed over into a network subsystem, which them starts to build the mesh structures, it is initiated by the streaming / loading end, rather than from the entity end. The async nature of it tends to require a staging area anyway and it makes sense to build those as the data comes in, not as a result of a createEntity call (which then can't be fulfilled).

But, this is getting OT now. If you want to follow this up further I suggest we move it to another thread.

[spookyboo]

You can do something in the tools department. One thing that comes into mind is a tool to deploy assets. I think I'm not the first one who's directories are polluted with unused textures, material, dll's, etc. Deployment often involves manual work, which can take some time and is error prone. The deployment tool for example, reads all material files and combines the materials into a configurable number of files in a target directory (reduces I/O). The same with textures, where unused textures (that are not part of a material) are discarded, unless you specifically list them. Only the executables, dlls, etc. that you really use, are deployed to the target directory; unused plugins - which are not in the plugins.cfg - are discarded, unless you explicitly include them.

[_tommo_]

Something to compile every ogre script into a precompiled binary zipped file.
Loading from a thing like that should be blazing fast

[madmarx]

Maybe, since you got experience with physics and animation, you could externalize the animation system ?

[syedhs]

You can do something in the tools department. One thing that comes into mind is a tool to deploy assets.

I second spookyboo, probably this time around, our Google summer code is full of tool, if possible all 6 of them!

The reasoning here are many folds (that I can think of):-

1) Tools are really not that hard to produce as it doesn't have to change Ogre's code at all (90%). So the possibilities of getting projects completed (and continued) are bigger than others. And not to say, the possibility of getting started in the first place

2) Tools IMHO, is the biggest hole in Ogre that need to be filled in.

Okay just two points, but the first point is very valid and justified, IMO. Having said all those, I remembers a point saying that tool is much customized to one's pipeline, which I think to certain extend it true. But to hobbist, casual programmer - having to simply use the tool is just plain awesome. Plus, most serious studio can take the tools' source code, rip them apart and build their own on top of it (rather than start from 0, they start from something rather concrete). Yes MIT licensed code. And we probably will see their code submission back although not required.

[sinbad]

Sorry to burst your bubbles guys, but tools projects don't work that well in practice for GSoC. We've had a couple of tools projects before, and they fizzled out. Problems include:

• A good tool is actually very difficult to finish over a summer. Tools require polish, and really they take longer than a few months.
• They're not core. They're the least likely to attract new contributors to carry on with them if the student doesn't stay on after the summer, and they don't contribute to the core feature set
• Good tools are aligned to a given workflow. This also makes them less general and less likely to be picked up after the summer.

I'm not saying it's not possible to create a good tool project for GSoC, but experience so far with tools projects in previous GSoCs has been pretty disappointing, to the extent that we would require some convincing to accept future tools projects. They have a tendency to get to 'alpha' stage over the summer and then fizzle out.

There's a damn good reason that tools are the least well populated area in OGRE, except for commercial offerings. Good end-user tools are hard, they're specific, they require a user-facing mindset which is often not that natural to developers, and are generally a long-term investment. That makes them hard to sustain even just as open source projects, never mind as summer projects.