[Crystal-develop] Google Summer of Code: For potential students

[Jorrit Tyberghein]

Hi all potential students for Google Summer of Code.

To get you started I recommend checkout the list of ideas we have (
http://www.crystalspace3d.org/trac/CS/wiki/SoC%20Ideas). Always discuss
here with us first because some of these ideas on that list are not fully
up-to-date and need some finetuning. We can talk more about it in detail if
you tell us what you would like to do.

Also feel free to come up with your own innovative ideas. It is also
possible to include CEL and Ares in your project ideas. I would very much
welcome Ares related projects for example.

You should also make sure to make yourselves comfortable with Crystal
Space. It is recommended you use the development (unstable) version of CS
(2.1) which you can get from svn (
http://www.crystalspace3d.org/main/Download_trunk). Experiment, read code,
try to do some tutorials. In other words: make sure you know what CS is all
about. And of course you can always ask questions here or on IRC
(#CrystalSpace in freenode.net).

About your proposal you will eventually submit to us: make sure it is
sufficiently detailed so we can judge if what you are going to do thisi
summer is good for us. You may be a brilliant programmer with splendid
ideas but if you can't convince us in your proposal then that is not going
to do you any good. This page (
http://www.crystalspace3d.org/trac/CS/wiki/SoC) contains a template you can
use for your proposal but remember that it is only a template. You will
have to provide the actual contents.

Also keep the GSoC timeline in mind (
https://www.google-melange.com/gsoc/events/google/gsoc2014). You cannot
apply right now but this is the good time to get to know each other, get
comfortable with CS, talk about your potential proposal and so on.

So good luck to all of you!

[Csaba Molnár]

[Christian Van Brussel]

Hi Csaba,

I'm sorry, your proposal has been much ignored so far.

Your project idea seems interesting, though.

The main concern I have is that this would a priori need to be
implemented as a new render manager, although there are already 4 in CS
and that they are not compatible with one another. Maybe this can be
overcame one day by adding in CS the ability to use several render
managers at the same time, eg one per different render priority?

Anyway, you can go on and submit your project proposal on Google
Melange.

Do you have some ideas on the way you would implement that in CS? Do you
want to discuss that here?

Christian

[Csaba Molnár]

Hi Christian,

thank you for your answer. Because of the lack of any reply or advice, I almost gave up.
It is good to hear that you find my idea interesting.
My first letter wasn’t really written as a proposal, I just wanted to know if my idea is suitable for CS, or what I should do to make it acceptable.
For this project, writing a simpler own render manager sounds the easiest way, but in the long run it would be nice to plan one manager, which would be able to handle all techniques.

I haven’t got a deep knowledge yet of how rendering works in CS, so the only thing I can write at the moment is the basic concept I planned for an own framework around the technique.

For the first prototype I planned three different renderer classes, VTRenderer (Volumetric transparency), ShadowRenderer and SolidRenderer. They are bound together in a wrapper class, which functions as a state machine, and its job is to control the whole rendering operation, and the communication between the renderers. Every renderer has an entity list. In every frame, every renderer gets a pointer for every entity, and they will store the entities they have to render. The true rendering part begins after the collection phase. Let’s assume that the shadow rendering mode is turned off, and we want to use volumetric transparency. Then in the first step the SolidRenderer renders solid entities into a texture. That texture is given to the VTRenderer. It will render transparent objects, and the result can be displayed on the screen.
The VTRenderer can use the normal vertex shaders, e.g. it can render an animated character without a problem. Being transparent wasn’t planned to be a static effect. Entities, which can be rendered as transparent objects, must be derived from a helper class, which contains the required data for the special rendering, like color, density, reference to a shader program, and a flag to show if it is solid at the moment or not. Due to multiple inheritance this is feasible. Diamond structure can not be formed, because this helper class is not derived.
Shaderprograms are stored in the wrapper class as well, and entities have pointers to them. The programs can be asked from entities by the Renderers.

I hope I formed my ideas in an understandable way.
Making this compatible with CS sounds like a true challenge. Sectors and portals… I have to dig deeper into CS to find a good solution.

What do you think about it?

Looking forward to receiving your reply!

Regards,
Csaba

Post by Christian Van Brussel
Hi Csaba,
I'm sorry, your proposal has been much ignored so far.
Your project idea seems interesting, though.
The main concern I have is that this would a priori need to be
implemented as a new render manager, although there are already 4 in CS
and that they are not compatible with one another. Maybe this can be
overcame one day by adding in CS the ability to use several render
managers at the same time, eg one per different render priority?
Anyway, you can go on and submit your project proposal on Google
Melange.
Do you have some ideas on the way you would implement that in CS? Do you
want to discuss that here?
Christian
------------------------------------------------------------------------------
Learn Graph Databases - Download FREE O'Reilly Book
"Graph Databases" is the definitive new guide to graph databases and their
applications. Written by three acclaimed leaders in the field,
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/13534_NeoTech
_______________________________________________
Crystal-develop mailing list
https://lists.sourceforge.net/lists/listinfo/crystal-develop

[Soumitra Saxena]

Hello all !

My name is Soumitra Saxena. I'm in my prefinal year , studying Electronics
Engineering at the Birla Institute of Technology and Sciences , Pilani ,
India. I've taken a keen interest in Computer Graphics/OpenGL for the last
2 semesters and am very excited to apply for GSOC under Crystal Space.

Basic Terrain Generation has been a project of mine , both at a personal (
https://medium.com/code-adventures/cccf50e961a9) and academic level. I've
also tried my hands on a basic planet generation using terrain maps (
https://medium.com/code-adventures/9df442973626).

I've also done a bit of scripting and GUI implementation in Maya (toolkit
for Cloud Generation)

A GUI Editor for Terrain seems to be a fantastic addition to the Crystal
Space interface. I thought of a rough prototype for a GUI Editor. Here is
the rough map -

A GUI Editor for Terrain -


A 3D GUI Editor for Terrain , based on the flexibilities provided by the
cseditor framework. Modelled on Maya's Editor for Fluids and Terrain (kind
of) . Single iSpace with panels containing the Tools. Add flexibilities
like toggle wireframe/textured , rotation , zoom , viewcube etc. Can even
add quick view options like Isometric and Orthographic angles. The
following tools can be provided for improved functionality , leveraging
Crystal Space's terrain handling libraries. We are basically making an
interface so that a new user feels comfortable with terrain generation and
does not have to worry about the pipeline behind it :

Tools to be implemented in the panels :

1. Generate Mesh tool :

a.Set number of cells and size of mesh.

b.Generate Flat Terrain with standard material and proceed to Edit it using
the Terrain Edit Tools.

c. Set Properties like Max Height , Mean height , Median height.

d. Preloaded presets - Desert , Grassland , Ice

2. Generate Terrain tool:

a. Load Heightmap and generate terrain , save values in the mesh to edit
later.

b. Set values like Max Height , weight and Resolution.

3. Material Properties :

a. Set attributes like Material Color , Material Type ( Phong , Blinn etc)

4..Edit Mesh tool :

a. Selectable points in the mesh using Mouse pointer . On click , 3D
Transformation tool appears , user can use deformations. Add option of
toggling off texture (display wireframe).

5. Paint Terrain tool :

a. Splatting Textures - Select a splatting texture from a list of textures.
Mouse cursor changes into the type of texture. Paint over the standard
texture with the chosen texture.

b. Choose from a variety of colors , terrain presets ( dust , grass , ice).

6. Add Object Tool (maybe):

[Christian Van Brussel]

Hi Soumitra,

one first note is that there was previously a GSOC idea about planet
simulation, it was described here:
http://www.crystalspace3d.org/trac/CS/wiki/SoC%20Ideas?version=177#Planetsimulation.

This project was worked on during the last GSOC, but the student didn't
got to the end of it and no code was commited. The blog defining the
working process is here: http://crystalspacegeodesicsphere.tumblr.com/

The idea was removed because one plan for that was to leverage on the
existing terrain mesh that is in CS, but it appeared during the last
GSOC that this was not easy to mix the two approaches and that the job
was a bit complex although not a priority for CS.

Another thing to know is that the terrain mesh in trunk doesn't support
currently the use of decals. I however already implemented this
functionality but never commited it. My work was almost done although
there was still some problems for decals that are covering several
cells. I'll try to commit that quite soon.

So now more about your project idea. A first remark is that we are at
first more interested by the manipulation of an existing CS terrain
rather than by the generation of it. So it would probably be preferable
if the generation part of your work would be put at the end of the
project rather than at the beginning, so that the main targeted
functionalities are the most worked on.

The order of importance we found for terrain edition is mostly the same
as what is listed on the GSOC idea page, that is (the first one being
the most important):
- Definition of the basic terrain properties (count of cells, size, etc).
- Use decals to display the mouse cursor and the current modification
primitive.
- Heightmap modifiers using different primitives and weight (see the
application csterrainedtest).
- Painting of the splatting textures.
- Painting of the decals.
- Painting of the mesh generator materials and properties.

Ideas such as presets are great but they are higher level
functionalities and should therefore be added in the end, if time allows
and the main functionalities are OK.

Also, the 'Add Object Tool' is more generic since this should work even
if there are no terrains, so I would remove this idea from your project
or keep it as very optional.

One of your main constraint would be to use the cseditor framework to
integrate all your work, and since the cseditor is still young, you may
have some issues like incomplete or non-working functionalities. You
would also probably need to work a bit using wxWidgets tools.

Does it look OK to you?

[Soumitra Saxena]

Hello Christian ,

Thank you for the reply.

About the planet generation , I did it as a part of my Computer Graphics
course in college . It seemed like a fun project ( and so it was) . I had
no idea you people actually tried it out on CS ! I was actually very
interested in terrains and all. Sad to hear that it's not a priority
anymore.

Anyways , about the Terrain Editor. When I read about the need of a GUI , I
just sat down and scribbled everything I would want in an editor. I
actually did not think of the timeline then , but in the past few days ,
I've been reading into GUI creation , the Terrain handling capabilities of
CS and the cseditor framework as well.

I think it's a good idea to target the project from the beginning , and
look for quality rather than quality.

The priorities that you've set are quite reasonable . (and now that I
re-read my idea , I feel that they are the core features over which a fully
functional GUI can be setup)

Taking csterrainedtest in context and the GUI aswell -

1. The first 3 points in your list should be taken care of initially and as
quickly as possible. The first being initialising the terrain with default
cell size and number , and then integrating the terrain->AddCell(cell) and
terrain->RemoveCell(cell) with the GUI. Heightmap modification should be
fairly easy to implement(hope so) , since we're handling a normal heightmap
with height values ( what I can understand from the code).

2. Splatting textures and Decals would be the interesting part . Decals
primarily , would be tougher to implement. I remember using the fragment
shader and using texture mixing to implement it in OpenGL . I'll have to go
through the CS code to find out how it is implementable in CS.

3. I remember using CodeBlocks for my C++ projects last semester , and I
think I've used something called wxSmith for a Software Development project
of mine. I , however , have no current idea of how to integrate it with CS.

I'm currently exploring the codes of various CS Tests to get a further idea
of how the libraries work. I'm somehow unable to get cseditor running right
now . But I'll try and get it to run asap , I really want to get a feel of
how it works.

So yeah , broadly , I would like to focus on the first 3 points of your
priority list , and then the Splatting and Decals. If time permits (
strictly ) , we may try implementing the other features in my email . How's
that for a proposal ? Also , what kind of details are you expecting in the
proposal ? Do you want it to be mildly broad , or do you want it to be
targeted as a needle ? Could you shed some light on it ?

A quick response will be really helpful !



On Sun, Mar 16, 2014 at 10:14 PM, Christian Van Brussel <

Post by Christian Van Brussel
Hi Soumitra,
one first note is that there was previously a GSOC idea about planet
http://www.crystalspace3d.org/trac/CS/wiki/SoC%20Ideas?version=177#Planetsimulation
.
This project was worked on during the last GSOC, but the student didn't
got to the end of it and no code was commited. The blog defining the
working process is here: http://crystalspacegeodesicsphere.tumblr.com/
The idea was removed because one plan for that was to leverage on the
existing terrain mesh that is in CS, but it appeared during the last
GSOC that this was not easy to mix the two approaches and that the job
was a bit complex although not a priority for CS.
Another thing to know is that the terrain mesh in trunk doesn't support
currently the use of decals. I however already implemented this
functionality but never commited it. My work was almost done although
there was still some problems for decals that are covering several
cells. I'll try to commit that quite soon.
So now more about your project idea. A first remark is that we are at
first more interested by the manipulation of an existing CS terrain
rather than by the generation of it. So it would probably be preferable
if the generation part of your work would be put at the end of the
project rather than at the beginning, so that the main targeted
functionalities are the most worked on.
The order of importance we found for terrain edition is mostly the same
as what is listed on the GSOC idea page, that is (the first one being
- Definition of the basic terrain properties (count of cells, size, etc).
- Use decals to display the mouse cursor and the current modification
primitive.
- Heightmap modifiers using different primitives and weight (see the
application csterrainedtest).
- Painting of the splatting textures.
- Painting of the decals.
- Painting of the mesh generator materials and properties.
Ideas such as presets are great but they are higher level
functionalities and should therefore be added in the end, if time allows
and the main functionalities are OK.
Also, the 'Add Object Tool' is more generic since this should work even
if there are no terrains, so I would remove this idea from your project
or keep it as very optional.
One of your main constraint would be to use the cseditor framework to
integrate all your work, and since the cseditor is still young, you may
have some issues like incomplete or non-working functionalities. You
would also probably need to work a bit using wxWidgets tools.
Does it look OK to you?
------------------------------------------------------------------------------
Learn Graph Databases - Download FREE O'Reilly Book
"Graph Databases" is the definitive new guide to graph databases and their
applications. Written by three acclaimed leaders in the field,
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/13534_NeoTech
_______________________________________________
Crystal-develop mailing list
https://lists.sourceforge.net/lists/listinfo/crystal-develop

[Christian Van Brussel]

Hi Soumitra,

about the project on planet simulation, if this is something that you
are really interested in then you can consider switching to a project on
that topic. Another possibility is to propose two separated projects
(terrain editor + planet simulation), this would increase your chances
to be selected although this would need more work for you to prepare
both proposals.

Some comments about the terrain editor:

* Yes, the terrain2 plugin in CS uses a classical heightmap texture. But
you shouldn't have to manipulate it by yourself but use instead the
iTerrainModifier tools such as in csterrainedtest. One of the advantages
of those modifiers is that they will allow to implement easily undo/redo
functionalities.

* About decals, you are not forced to implement a solution by yourself
and the one that I will commit should be good enough, at least to start
with. The one that I implemented doesn't use shaders but instead an
additional mesh for the decal. It would be possible to implement another
one using shaders, and you can add this functionality if that is
something you are interested in, but this can be kept as optional since
this is not a priority.

* About wxSmith, I guess it can be problematic to use it here since it
will be a bit tricky to interface with the cseditor framework that
manages by itself most widgets. Other tools such as wxFormBuilder can be
used otherwise in order to define GUI portions through .xrc files,
although my personal preferences goes often to the manual creation and
manipulation of the widgets.

* About cseditor that you don't manage to get running, you can throw us
your error messages so that we can see if we can help.

* Maybe a functionality that can be added is the check for having
correct saving/loading of all terrain properties. This is supposed to
work correctly but you may find some few problems when playing with it,
and you may have to dig for them by yourself.

* For the proposal, a part of the challenge is clearly to try to find
the equilibrium between concision and completeness, but I guess telling
you that won't help you that much :) The list of tasks and targeted
goals should appear clearly, along a timeline and some global
implementation consideration such as the CS/cseditor tools that you
would use and the way your code would interface with them. Try to show
to the mentors that will read you that you know what you are talking
about.

[Soumitra Saxena]

Hello Christian ,

I've uploaded a draft of my proposal at my GSoC profile.

Kindly suggest changes and edits asap ! I'd really like to polish my
proposal before the deadline !

Thanks and Regards.


On Mon, Mar 17, 2014 at 8:36 PM, Christian Van Brussel <

Post by Christian Van Brussel
Hi Soumitra,
about the project on planet simulation, if this is something that you
are really interested in then you can consider switching to a project on
that topic. Another possibility is to propose two separated projects
(terrain editor + planet simulation), this would increase your chances
to be selected although this would need more work for you to prepare
both proposals.
* Yes, the terrain2 plugin in CS uses a classical heightmap texture. But
you shouldn't have to manipulate it by yourself but use instead the
iTerrainModifier tools such as in csterrainedtest. One of the advantages
of those modifiers is that they will allow to implement easily undo/redo
functionalities.
* About decals, you are not forced to implement a solution by yourself
and the one that I will commit should be good enough, at least to start
with. The one that I implemented doesn't use shaders but instead an
additional mesh for the decal. It would be possible to implement another
one using shaders, and you can add this functionality if that is
something you are interested in, but this can be kept as optional since
this is not a priority.
* About wxSmith, I guess it can be problematic to use it here since it
will be a bit tricky to interface with the cseditor framework that
manages by itself most widgets. Other tools such as wxFormBuilder can be
used otherwise in order to define GUI portions through .xrc files,
although my personal preferences goes often to the manual creation and
manipulation of the widgets.
* About cseditor that you don't manage to get running, you can throw us
your error messages so that we can see if we can help.
* Maybe a functionality that can be added is the check for having
correct saving/loading of all terrain properties. This is supposed to
work correctly but you may find some few problems when playing with it,
and you may have to dig for them by yourself.
* For the proposal, a part of the challenge is clearly to try to find
the equilibrium between concision and completeness, but I guess telling
you that won't help you that much :) The list of tasks and targeted
goals should appear clearly, along a timeline and some global
implementation consideration such as the CS/cseditor tools that you
would use and the way your code would interface with them. Try to show
to the mentors that will read you that you know what you are talking
about.
------------------------------------------------------------------------------
Learn Graph Databases - Download FREE O'Reilly Book
"Graph Databases" is the definitive new guide to graph databases and their
applications. Written by three acclaimed leaders in the field,
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/13534_NeoTech
_______________________________________________
Crystal-develop mailing list
https://lists.sourceforge.net/lists/listinfo/crystal-develop

[Christian Van Brussel]

Hi Csaba,

there are already a set of functionalities in CS to manage most of that
rendering stuff, that is the render managers (RMs).

The documentation in the manual for that is a bit outdated, but you can
have a look eg at the deferred RM at
http://www.crystalspace3d.org/docs/online/manual/Deferred-Shading.html.

There is also the part on the render priorities that is relevant here in
order to define the objects that are transparent:
http://www.crystalspace3d.org/docs/online/manual/HOWTO-Render-Priorities.html.

You can also have a look at the code of the RMs in
CS/plugins/rendermanager, the 'unshadowed' RM being the simplest one,
hence an interesting starting example.

So here you would concentrate mainly on the implementation of a new RM +
its set of shaders, that is, mostly the part relevant to the management
of the transparent objects. Those transparent objects would be defined
using a dedicated render priority. And the first 'deferred' step of your
algorithm would be implemented using the regular CS tools in
libs/csplugincommon/rendermanager.

It would also be possible to change the topic of the project and work
more on adding the ability in CS to mix several render managers, but
here we would first need some feedback of other CS developers to gather
some opinion on the relevance of such idea.

[Matthieu Kraus]

Post by Christian Van Brussel
Hi Csaba,
[...]
So here you would concentrate mainly on the implementation of a new RM +
its set of shaders, that is, mostly the part relevant to the management
of the transparent objects. Those transparent objects would be defined
using a dedicated render priority. And the first 'deferred' step of your
algorithm would be implemented using the regular CS tools in
libs/csplugincommon/rendermanager.

I don't think it'd be necessary to add a new RM for this. Deferred
itself is pretty
generic so it should be sufficient to add support for the required
extensions and
add a new shaderset based off the deferred sets that is able to handle alpha
objects in a deferred manner (and remove the according priorities from
the forward
shading list). Note that alpha objects already have to be defined
using according
priorities to work with deferred, so there wouldn't be any new
requirements for that.

kind regards,
Matthieu "RlyDontKnow" Kraus