This thread is a great idea.
Allow me to contribute.
These days we (girlfriend and me) is getting ready to release our first “Blu-Play” game. (www.blu-play.com)
So today we (that means her, because she’s the graphics artist) have created a label and cover for the Blu-ray Disc. 
If you’ve been following US “politics” and media the last time and wonder… what the eff…, you must see this:
I just find it so hard It so hard to find John Oliver and Trevor Noah on Comedy central funny 
I liked having colbert on 24/7 on the station; Was a lot more enjoyable.
Today I poked at a generic signature. Next thing I know it had exploded all over my entire class hierarchy. That’ll teach me. Still, it is done now.
Cas
Thanks for the tip! Will try.
Was thinking of ways to add 3D buildings to the level, created a function that will create one big block or a block split up into X number of blocks at random. As I am using Box2D for the collisions (game is topdown 2D) it adds collision boxes where 3D objects are on the floor.
Next I will change clicking on tiles to open up an editor where you can make objects using cubes and some other shapes and apply texture to them.
Once I have a basic level editor will add load / save and a chunk manager.
I forgot Valentine’s day
But I deployed v0.1 of my new website:
http://beyondproxima.appspot.com/
It is a clickable 3d map of the stars near us. Click the star’s Hipparchos catalog name to fly to the star at 10,000,000 times the speed of light.
It’s coded with SVG, JS and Java.
(The JS is crude and brutal, view source to have a laugh ).
Tackled one of the bigger components of my engine that I’d been putting off implementing. On and off, took me about a week, but I present 0.42 alpha of the Morningside Engine and the joint editor!
It was pretty tricky wrapping box2D joints in a way to work with my internal formats but I think it makes a powerful addition to the engine. They also save and load with maps, so they persist 100%.
I’m half-tempted to make a version of gMod at this point 
These last few days, I’ve worked on improving the RF graphics, since that’s one of the main criticisms we got for it.
We don’t really draw our houses in RF; we just draw the walls on the ground and leave the rest to the user’s imagination. Now, some time ago I added a day/night-cycle, where the ambient light changes over the course of the day, with nice orange mornings and sunsets, and really dark nights. It’s really nice, but didn’t really have much impact due to the lack of shadows. I realized that I could really easily draw some sun shadows using the same shader and system as for point lights, allowing for a full day/night-cycle with the sun casting long shadows from the buildings, which even have faked roofs casting shadows now, which helps conveying the actual size and shape of the house even though we don’t draw it.
I also added cloud shadows that slowly float over the screen and change shape, and added a cloudiness parameter that allows the clouds to be slowly faded in and out, allowing for transitions from a sunny day to a cloudy day over a couple of minutes of playtime, with really good results. I had to make a few compromises on the clouds though, as I really needed bicubic filtering to get them to look good. Still, I’m happy with the results.
Today I added “raytraced” god rays based on said clouds. It’s pretty crazy heavy, but done at 1/16th the normal tile resolution so it’s not too slow. They’re accurate and follow the shape of the clouds as they float by. The intensity of the clouds are faded in based on the cloudiness parameter, so on clear days the god rays will essentially disappear to avoid turning the entire screen white, while on cloudy days the intensity ramps up so that a tiny hole in the cloud cover will cast a glorious pillar of light to the ground.
Here’s a pic showing off all the new features:
Today, I wrote a mesh optimizer in Java to be used on the output of my Blender export plugin.
I’m not too proficient in Python and it’s just so goddamn slow at everything, so instead of completely ruining the fast export times I’ve managed to get so far, I opted for writing a simple optimizer that takes in a model file, optimizes it, then writes it out again. This is done in 3 steps:
In the first step, I simply eliminate all duplicated vertices and leave just one of each, then reference the same one with an index buffer. The mesh I output from Blender is mostly unoptimized with lots of duplicated vertices, and this step reduces the vertex count by about 75% percent. This saves a lot of memory on the harddrive and reduces loadtimes a lot, but it actually does not improve performance very much. For example, in one of the submeshes of the giant robots of Robot Farm, the vertex count goes from 38544 --> 9248, a 76% reduction, but the number of vertex shader invocations only drop from 38544 --> 26902, a 30% drop. This leads to the next step…
In the next step, the triangles in the mesh is reordered to improve the effectiveness of the hardware vertex cache. As some people might remember, I’ve done a lot of experiments on the hardware vertex caches of Nvidia, AMD and Intel GPUs, and basically concluded that Nvidia’s is fucking weird, AMD’s is kinda weird and Intel’s is the only sane one. In the end, I concluded that optimizing the meshes for each graphics vendor was too much work, so I simply went with a mainstream algorithm. I ended up implementing Tom Forsyth’s simple algorithm, and it works really well. This algorithm simply reorders the triangles in the mesh (by reordering the indices in the index buffer) to increase the chance that vertices are reused as much as possible without specializing it too much to a specific cache size. It’s pretty much a general-purpose optimization that should be better than nothing. Anyway, this step further reduced the vertex shader invocation count from 26902 --> 11847, which together with step 1 was a total reduction of 70%! Now, optimally, the number of invocations should be equal to the number of vertices in the mesh, which would mean that there is perfect reuse of vertices and no vertex had to be transformed more than once, but it may not be possible to achieve this. In the end, for this particular mesh the number of invocations is 28% more than optimal, which is acceptable to me.
Now, the meshes are optimized for the vertex cache and need a minimal number of vertex shader invocations, but there is one last thing that can be optimized. Inspecting the actual index buffer generated after step 2 reordered the triangles, it’s pretty damn random.
[quote]…, 6031, 5989, 5991, 5992, 5993, 5991, 6032, 5992, 5994, 5995, 5996, 5994, 6033, 5995, 8387, 8388, 8389, 8387, 8409, 8388, 8390, 8391, 8392, 8390…
[/quote]
There’s a lot of good reuse happening here, but also very huge jumps in which vertex each triangle uses. It essentially reads a completely random vertex from the vertex buffer each execution. This is bad for the GPU, as the vertex data from the VBO is read in with a certain cache line size depending on the GPU. In short, if you reference vertex 1000 and 1001, there’s a big chance that the memory read for the data of vertex 1000 will cause the data for vertex 1001 to also be loaded into the cache. Therefore, it is a good idea to try to minimize the “distance” between each subsequent index in the index buffer to increase the chance of the input data of the vertex shader already being in the cache. I did this by simply reordering the vertices in the data to so that they are in the order that the index buffer references them. This does not change the triangle order; it simply changes where the vertices of each triangle lies in memory. Here’s an excerpt from the output index buffer:
[quote]…, 2571, 2565, 2571, 2568, 2566, 2567, 2572, 2571, 2566, 2572, 2572, 2567, 2573, 2571, 2574, 2568, 2569, 2568, 2574, 2569, 2575, 2570, 2569, 2574, 2575, 2575, 2576, 2570, 2571, 2572, …
[/quote]
Much better! This works super well with the optimized triangle order from step 2, as the algorithm tries to place all uses of a given vertex in one place so that it can be reused, so there’s a very low risk of a very old vertex being referenced again. To measure the effectiveness of this step, I measured the average “index distance”, which is the average [icode]abs(currentIndex - previousIndex)[/icode] over the entire index buffer. The average index distance went from 42.82251 --> 5.490958, a very significant improvement to cache coherency!
All in all, here are the final results for the mesh:
Placing 500 of those high-poly robots with no LOD or anything in a test program, my FPS went from 12 to 32 when I switched to the optimized mesh, a ~62.5% reduction in frame time, which matches very well with the ~~70% invocation reduction when you add postprocessing and everything else taking up a bit of time in the first place.
This has nothing to do with java, but it doesn’t happen every day. I found a bag of drugs on the ground on my way to work. If it was weed I would be very happy, but since it’s white, I’m not sure what to do with it. Maybe I’ll go ask a cop what it is lol, but then again, I live in Chicago and would promptly be arrested for possession of a controlled substance.
Chuck it in the bin. Seriously. No good ever comes of white powdered drugs.
Cas
Chuck it in the bin… with your fingerprints on it?
Today I put my engine into Astah to see how the things are connected…
I didn’t include the terrain package and shaders code but I think that still valid.
Ps: I’m really open to suggestions about the initial architecture (I know that was a mess ??? :’( )
Ps2: hope to help someone to realize how the game/engine architecture can be initialized.
Imgur: http://imgur.com/jHLHKjX
Lightshot: http://prntscr.com/ea6f2a
This isn’t java or programming related. But i’ve now learned a pretty good amount of meshuggah songs on the drums!
Here’s the list as of today:
-New Millenium Cyanide Christ
-The Exquisite Machinery of Torture
-Sickening
-Future Breed Machine
-Beneath
-Soul Burn
-Inside What’s Within Behind
-Marrow
-Humiliative
-Stengah
-Rational Gaze
-Glints Collide
-Spasm
I’m currently working on learning Closed Eye Visuals
Now, for the java related thing:
I’ve completed the javadocs of the engine!
I registered my company site and installed MediaWiki Also made a logo, which I quite like.
http://www.onedropgames.com/
If I wanted to post a WIP about my engine in the coming days, would it be okay?
You never fail to amaze me, agent. Never thought that index ordering could have such an impact. This topic is now definitely on my (long) list of TODOs. Are games nowadays always optimizing this? And…since you implement so much stuff, why don’t you share your repository or your code? :point:
Thanks. =P
I’d imagine most games do something to optimize this since the gains can be so huge. In my case, it was really going from the worst possible case to almost optimal reuse, so my gains were a bit exaggerated.
Here’s the code for my triangle order optimizer: http://www.java-gaming.org/?action=pastebin&id=1508 My implementation is O(n^2), so not entirely optimal according to the original paper. Still, it’s fast enough for my uses. A 12 848 triangle mesh took 260ms to optimize for me, so good enough for an offline tool. There’s some low-hanging fruit in there to optimize.
Here’s the pre-vertex cache optimizer code. http://www.java-gaming.org/?action=pastebin&id=1509 Very simple, there’s probably much better algorithms out there, but I couldn’t measure significant gains from running this anyway.
Note: You should always run the triangle order optimizer FIRST, then run the pre-vertex cache optimizer. The triangle order optimizer messes up the vertex order, which the pre-vertex cache optimizer fixes without changing the triangle order.
I seem to recall years and years ago getting perfectly decent performance optimisation just by the simple expedient of sorting triangles in order of their average vertex index number. And that’s O(n log n) perf on average. It’s not quite as fancy but it gets like 90% of the win for bugger all effort and the best bit is that it can be done in realtime with dynamic meshes. Food for thought. (Why not try it and compare?)
Cas
