The most interesting questions for me would be how the development using jME was, and if you
plan new projects with it. I saw that bigpoint is hiring unity3d-people. Is this a consequence of one
year jME? 
And of course the most important question, if there will be a chance that you provide some code snippest
that might be useful for the community… e.g. the cinema4d-pipeline might be very interesting to make jME more
attractive to cinema4d users as well.
lanmower said:
Isnt the eyes a bit poly-heavy? they look rather smooth for a game model... Great work btw.
Hehe thanks, for calling it great work and for calling the eyes poly-heavy since they have only 50 polygons (25 per eye), smoothing groups are just making them look that great ;)
ttrocha said:
The most interesting questions for me would be how the development using jME was, and if you
plan new projects with it. I saw that bigpoint is hiring unity3d-people. Is this a consequence of one
year jME? :D
well we got ups and downs with jme but so far no downs as low as that we would give up on it and we made huge improvements over the past year (dynamic object grouping almost quintupled (!) the performance for example) but working with shaders could be more convenient, it seems like a lot of examples do only work for that special scene but look borked when used in different settings together with a lot of other features (EG. PCF Shadows + Normal Maps).
i can't tell if we plan other projects with jme, right now we focus just on Poisonville - Unity3D is a different compartment, so no idea about their plans either - the poisonville editor is capable to realize all kinds of projects though ;)
and no, the consequence of one (+) year jme will be a kick ass game :D
And of course the most important question, if there will be a chance that you provide some code snippest
that might be useful for the community... e.g. the cinema4d-pipeline might be very interesting to make jME more
attractive to cinema4d users as well.
well, cell and portal has been mentioned a lot so we see what we can do there. hehe we got no cinema4d pipeline since we are modelling in 3dsmax or maya and export as obj. i use cinema to check light settings, ambient colors, fog values, skygradients, normal maps and such but i do not export meshes - the meshes already exist. we got an own internal fileformat for the animations which is basicly something like a stripped down collada file with all the junk removed and some broken outputs auto-fixed. but to answer in general: yes, we'll share some code :)
denzer said:
but working with shaders could be more convenient, it seems like a lot of examples do only work for that special scene but look borked when used in different settings together with a lot of other features (EG. PCF Shadows + Normal Maps).
Definitely could be more convenient. I have had issues with this exact thing while working on my own projects. jME2 just wasn't built for shaders, they are essentially a second-class feature in jME2.
jME3, on the other hand, has this feature called shader libraries, you have files like shadow.glsllib, texture.glsllib, etc which you can "import" in your shaders like you import classes in Java. This allows complex effects to be combined in one shader (like PCF shadows + normal mapping).
In addition, jME3 includes define based "uber-shaders", where the shader behavior can be configured at runtime using defines which are placed by the artist inside material files, these are automatically included in the shader when it is used. You can use this feature to have only one lighting shader, that can be configured to handle multiple scenarios, with/without shadows, or with/without fog, etc.
This is great work you're doing here, but it might be a lot of trouble trying to get jME2 to handle these heavy shader-based effects.
Momoko_Fan said:
This is great work you're doing here
thanks, i'll forward it to the team ;)
but it might be a lot of trouble trying to get jME2 to handle these heavy shader-based effects.
it really is but so far we got everything working: Bloom, DoF, PCF Shadows, Reflections.. it's just pretty expensive, thats why we postponed the SSDO/ASSAO for now (although it's technically done) - that's stuff for later next year but it sure looks awesome :D
well, cell and portal has been mentioned a lot so we see what we can do there.
Please. Please. Please.
I'm even starting to consider coding it from scratch even though we have several developers on top of it, a look at the code even if it is game-specific will shorten the development time to complete portal systems in jme.
lanmower said:
Please. Please. Please.
I'm even starting to consider coding it from scratch even though we have several developers on top of it, a look at the code even if it is game-specific will shorten the development time to complete portal systems in jme.
i got bad news, we are not using cell & portal - at least not yet. we use some sort of "dynamic-preselection-culling" if you can call it that, its not based on any paper to name it proper. if someone can point us to or provide us with the latest state of development (code) regarding jme cell and portal, we'll take a look at it and discuss how much time it would cost us in our production timeline and if it's worth the extra cost. of course we would share the result with the community :)
i apologize for any confusion about poisonville and the "cell and portal" feature, it was planned in the beginning but abandoned since our culling method works pretty well - none the less it's still interesting for us, every frame counts ;)
i apologize for any confusion about poisonville and the "cell and portal" feature, it was planned in the beginning but abandoned since our culling method works pretty well - none the less it's still interesting for us, every frame counts Wink
Okay, of course it's bad news! But for me, I can now even more concentrate on this, cause I don't have "well, it's nice and pretty, but anotherone already made this..." in mind :wink:
Currently, there are some few bugs to fix in the algorithm, than I will start making Anti-Portals, and an damn-small api for editors to work with cell-and-portal..
so how about letting us peer over your culling system then? every bit helps 
lanmower said:
so how about letting us peer over your culling system then? every bit helps :)
I agree with lanmower. Moreover, if you could release any piece of code concerning your attempt of implementing the cells-and-portals algorithm, it could be useful. I go on saying implementing such an algorithm (computation of cells and portals, portal culling) from scratch working on any map would require months or even years of work for a single programmer.
gouessej said:
Moreover, if you could release any piece of code concerning your attempt of implementing the cells-and-portals algorithm, it could be useful. I go on saying implementing such an algorithm (computation of cells and portals, portal culling) from scratch working on any map would require months or even years of work for a single programmer.
goussej, have you considered that perhaps cells-and-portals "aren't for you"? There are many less complex algorithms out there concerning with scene partitioning and many of them are quite as effective as cells and portals except without all the headaches and difficulty that come with it. Maybe that is why poisonville have decided not to use this algorithm?
I was able to implement a triangle-based octree for rendering and collision in about 30 minutes. Heck, even Blender uses octrees, and that's for software ray tracing which must be blazing fast!
Momoko_Fan said:
goussej, have you considered that perhaps cells-and-portals "aren't for you"?
I'm not the only person interested by this.
basically momoko_fan is right, we dumped the cells and portals method in favor of the culling, which is simple and does what we need. technically all we do is having different flags for different objectgroups, so we can define at what distance they get culled - the traditional "viewing distance", just per group. of course it's way more complex then it sounds here but in the end that's kinda how it works.
lanmower said:
so how about letting us peer over your culling system then? every bit helps :)
i'll ask :)
gouessej said:
...Moreover, if you could release any piece of code concerning your attempt of implementing the cells-and-portals algorithm, it could be useful.
our cell-and-portals attempts never made into code - we focused on culling pretty early and abandoned the cells and portals idea when culling turned out to be fine for us. it was only just theory on the chalkboard, sorry.
denzer said:Golden nugget there in design before execution guys ;) That's a valuable contribution right there!
our cell-and-portals attempts never made into code - we focused on culling pretty early and abandoned the cells and portals idea when culling turned out to be fine for us. it was only just theory on the chalkboard, sorry.
erlend_sh said:
Golden nugget there in design before execution guys ;) That's a valuable contribution right there!
thanks :D although we did a lot of try and error too but mostly with import formats and tilesizes. we got a tight schedule so there is little space for experiments :)
i would like to adress an issue my lead coder pointed me to and please correct me if im wrong but it seems like VBOs are "broken" in jmonkey. the usage of VBOs seems to slow down performance rather than increasing it - display lists are way faster: testcase, large viewing distance: VBO 50fps, display lists 700fps -> huge bug? we made a test with testcubebumpmapping rendering 150 million textured and lighted tris with display lists - with VBOs that dropped to 5-6 million... pure immediate mode also just 5-6 million, which seems odd. if VBOs are emulating display lists (not sure if they do it that way, just assumed), the performance shouldnt differ that much. can anyone shed light on this "phenomenon"?
i would like to adress an issue my lead coder pointed me to and please correct me if im wrong but it seems like VBOs are "broken" in jmonkey. the usage of VBOs seems to slow down performance rather than increasing it - display lists are way faster: testcase, large viewing distance: VBO 50fps, display lists 700fps -> huge bug? we made a test with testcubebumpmapping rendering 150 million textured and lighted tris with display lists - with VBOs that dropped to 5-6 million... pure immediate mode also just 5-6 million, which seems odd. if VBOs are emulating display lists (not sure if they do it that way, just assumed), the performance shouldnt differ that much. can anyone shed light on this "phenomenon"?
Can't really tell you what's wrong. But VBO was added to jME later on so there was not enough effort put into integrating them with the core. One possible problem is memory leaking (which applies to display list also, btw). When you create lots of objects with VBO, they get allocated, but never destroyed. You must call Renderer.deleteVBO to manually delete vbos that are not used anymore.
It also depends on the video card and driver, old video cards and old drivers might have performance issues related to VBOs.
Besides that, I am not aware of any problems relating to VBO specifically. jME 3.0 for example uses VBOs entirely for rendering. Their usage is tracked automatically by the engine and they are deleted when no longer referenced by user code so memory leaks don't happen.
thats cool, I'm dripping to get my hands into jme3.
As for vbos in jme2 I should consider trying lists for my projects and see if theres a speed improvement…
i would like to adress an issue my lead coder pointed me to and please correct me if im wrong....
Actually I wondered some time ago already, you coders are not in the forum? How can this be? :?
ttrocha said:
Actually I wondered some time ago already, you coders are not in the forum? How can this be? :?
they are.. just undercover and they are contributing as well :D sry for the late reply - i've been too busy lately to update this thread but i'll be back in a few days with some fresh screenshots. no news regarding sharing code yet though, right now we got other priorities but it's on the list :)
cheers,
denzer
denzer said:
they are.. just undercover and they are contributing as well :D sry for the late reply - i've been too busy lately to update this thread but i'll be back in a few days with some fresh screenshots. no news regarding sharing code yet though, right now we got other priorities but it's on the list :)
cheers,
denzer
Let the witch hunt begin! :P
Good to hear you guys are busy though, looks like you have a release coming up!