In a week, Google Summer of Code 2015 will open up for applications. Based on our lessons learned last year, we’re approaching GSoC a bit differently this time around.
If we get accepted for this year’s GSoC, we will heavily prioritise known members of the community.
In other words, things that would look good on a student’s application include:
Hub membership & participation since February 2015 or earlier
Proof of work done using jME (anything from a game to a bug report)
An on-going jME project
We prioritise this way because we’re looking for students who don’t need GSoC as an incentive, but rather see it as a rare opportunity to commit yourself full-time to what is already one of your passion-projects.
Furthermore, we might not spend the hours required to apply unless we can determine genuine interest in the event from within the jME community.
So if you’re a student who’s thinking about maybe working on a jMonkeyEngine project this summer, please make yourself known in this thread.
I’d very much like to participate in this year. I am brushing up my Java skills and I’ve been with jME community for many years(since alpha 2) this would be a great opportunity for me to be able to contribute back.
Well, yeah, I’d probably be looking into that too… @erlend_sh could you say more on how you envision a possible participation effort? From reading the “lessons learned…” I think that there is something defined in what it all is going to be about?
I don’t understand what you mean by “how you envision a possible participation effort” or “is something defined in what it all is going to be about?”. Could you rephrase?
We don’t have any specific projects in mind yet if that’s what you’re referring to. The students will have to help pitch ideas for that, but I guess we have many ideas left over from last year that could be revisited.
I think JME should definitely participate because it’s a great opportunity for the engine to grow and for users to contribute something. I’d personally love to take part but unfortunately I have to do a lot of stuff for my finals…
What about the projects from last summer? I’ve seen some of them but the cinematic editor for example isn’t released yet is it?
In my opinion, if we make a project, it should be core this year as opposed to suuport librarys.
→ If it is core logic, it will automatically benefit the most people.
→ It is way easier to maintain, as many people use the core, but only few use specific extensions.
I agree that core improvements should be higher priority than anything else, however focusing entirely on rendering optimizations is probably not a good idea. First of all, 3.1 already has lots of improvements in the renderer, especially the lighting and shadow improvements (“optimizations for forward lighting” & “shadow casting” in your list).
For 3.2, which is probably what GSoC 2015 is going to be about, I would like to see see improvements in the art pipeline. This is where a lot of commercial engines have the advantage over jME and it would be great if we could bridge that gap.
For example this kind of work by @david_bernard_31 would be an excellent GSoC project.
Another thing we are sorely lacking in is animation and particle effects (or just special effects in general). I was prototyping a scripting language specifically for special effects and this is something that would be very cool if implemented.
I totally agree, especially in the asset pipeline stuff that are many still open things.
It would be great if we could load improve the support for existant shops/ect.
Eg Renderiosity and Unity store both allow useage of bought stuff in any engine.
Off the top of my head, being able to import animations without having to bake IK or having one root bone at 0,0,0 or other weird / silly requirements - but I guess this mostly pertains to art pipeline. Other things such as supporting shape key / morph animations, and computing bounding volumes for each animation are also important.
I guess this would be a part of cinematics in some sense. Cinematics, complex animations, and special effects are all basically doing the same thing, and there needs to be something similar to the J3MD / J3M formats we use now to compose those.
Last year we approved a lot of projects which had little or almost nothing to do with jME. What David is working on allows artists to edit the model in a familiar tool, being able to preview it in the engine, and then import it easily. This is exactly the sort of thing we need in our art pipeline.
I think more advanced animation capabilities like something Unity has. Unity has an easy way to build a state machine on top of the animation controller that lets you set up states and how to transition between them. It’s pretty powerful and would be a wonderful addition to JME. I know I have something like that setup for my project but not nearly as awesome.
Particle systems like those found in Unreal 4 and Unity would be pretty awesome too. Thinks like animation curves for particle attributes would allow a lot of creative control. I had to setup a system like that for my game but it isn’t integrated into the sdk which is cumbersome.
Well david is a bit too old to be a student (no offense @david_bernard_31 )
If we pick something core, like particles, animations or deferred rendering, we have to make sure the student is very capable. Also if we go to GSoC this year, and I’m a mentor, I’ll be a bit more picky on the student.
Also remember that the project must appeal to Google so that we can have slots…
I’m not sure what exactly the rules are for the GSoC but would it not make sense to make an open source game using JME rather than trying to make add-ons or improvements to it.
That way students who want to use the engine learn a lot about it from someone with advanced knowledge of openGL and what not.
You’d think students wouldn’t be in the position to contribute directly to the engine due to inexperience and lack of confidence to take on a huge project, but rather would learn to use the ins and outs of the engine itself with the help of a more experienced developer.
Yep, it would. We had it as an idea in earlier GSoC applications. For some reason we didn’t in 2014, but we did have “Android Demos”. With the experience we’ve had so far with our newest example game project, I would love to do others like it. We could have an overarching “Example Game” category and think of 3-4 suitable projects.
As mentioned, improving the assets pipeline is a major priority. The FBX Importer would definitely make for a great project. @Eirenliel and @tort32 are there any students among you in your team?
Heh, sorry for dragging you into the GSoC discussion with no warning Search for “Google Summer of Code” and you can find out more. I’m just talking about making your FBX Importer a possible GSoC project, i.e. a student would get paid to work on it. A core developer/contributor would probably mentor it, but the student and mentor would be collaborating with you. If it’s confusing don’t worry, more will be explained later
I think, improving assets pipeline can be a great project and awesome improvement to jME. We had some problems with organizing assets in our game and developed some tools for it. FBX importing is not the only problem, there are a lot of tasks that can be supplied.
In case of formats support it will be awesome to have support of substances from Substance designer.
(no offense 
)
Search for “Google Summer of Code” and you can find out more. I’m just talking about making your FBX Importer a possible GSoC project, i.e. a student would get paid to work on it. A core developer/contributor would probably mentor it, but the student and mentor would be collaborating with you. If it’s confusing don’t worry, more will be explained later