Prepping for the Canada Wide Science fair⦠Iāve finished my 5-page paper, the computer is built, everything is weighed to be transported through plane, and Iāve been working sleeplessly on the project board. Thereās around seven days left until my flight. ;D
Thanks. Seems like the apartmentās mostly okay, and it doesnāt look like all hope is out for the summer job, although it wonāt be what I expected and it seems like itās not as much as it initially was. Well, better than nothingā¦
As long as youāve got some source of income, youāll be fairly better off than a lot of other people. Iām sure there are plenty of jobs available for programmers though, especially talented ones?
Finally found time to do some programming
Created a working (but featureless ;c ) raycast renderer:
And a copy of Conwayās Game of life:
If you really want to try them here are the links: DoomTest.jar (Left Right Up Down - move, zx - look) GameOfLife.jar (space-run, as - increase/decrease step time, mouse-draw)
My only income is student aid, and I donāt get that during the summer. The problem is that I declined my previous summer job to get that one⦠Luckily it seems like not all hope is lost with the new one, although it seems like itāll be a different task than what I had in mind.
I tried (and achieved) doing multi-threaded application using GLFW (My OO wrapper for GLFW actually).
This uses immediate mode mainly since it is a test, but the other tests are indeed modern GL. Will soon update this one. Source code is available here: GLFWMultiThreadTest.java
Bought a Windows Phone to test out and see if I like WP. Also probably going to get into developing apps for it if I actually do end up upgrading my current phone to a WP, which could be fun! I also have been working at getting my internship pretty hard, hopefully Iāll know here in a few days.
Red, green blue (x4 or x5) are physics updates. We do 250 updates per second to get good collision detection, so multiple ones are done for each frame rendered.
Red is the first threaded pass, where the position is updated based on velocity and then body-ground collisions are solved.
Green is the second pass where body-body collisions and body-triangle collisions are solved.
Blue is the third pass where body-ground collisions are solved again to eliminate any risk of falling through the ground (working on eliminating this).
Lastly, thereās a fourth pass (white) which is so fast itās not visible. Itās a single-threaded task which updates the body data structure in a thread-safe manner, but since it only processes bodies that actually need updating (checked in pass 4), itās almost instant.
The last tasks are for the rendering of the game.
Purple is actually part of the physics engine. It interpolates transforms for each body so the instance gets a properly interpolated matrix (allowing >250 FPS and reducing stutter at <250 FPS).
Then thereās a gap, which comes from updating some rendering data (updating the animation frame of all 3D models, the camera) which is single-threaded in this threading program.
Yellow (single-threaded) is the light culling. Itās fast so no real need to thread it.
Brown is 3D model āresettingā which prepares the 3D models for being culled by updating their bounding box. It also handles instance ID handling for SRAA.
Black is shadowed light matrix generation, which generates views for shadow maps to be rendered.
Reddish (single-threaded) is octree generation for model culling.
Light blue is terrain culling. It determines what terrain ātilesā are visible and constructs instance lists for each view (each light in that scene has 6 shadow maps which are also handled here).
Pinkish is model culling. Constructs instance lists for all views for 3D models.
Dark blue is terrain tile data packing in VBOs (an invisible green task maps the VBO after culling is done).
Red is model skeleton calculation and VBO uploading of instance data and visibility data for each view.
( - Last blue task is a rogue tile data packing subtask.)
Finally, the last black task (running on the top OpenGL thread) sends off all draw calls for the entire scene to the driverās internal thread.
There are some other tasks too but they are too fast/simple to mention (3 buffer mapping and 3 buffer unmapping tasks)
1 thread: 14 FPS
8 threads: 48 FPS (Fraps screwed up the FPS in the screenshotā¦)
= 3.43x scaling on a quad core with Hyper-threading. Quite good considering all the draw calls are single-threaded due to how OpenGL works and the driver only has 1 internal thread.
EDIT:
Realized that the skeleton calculation was way too slow. Turns out I was calculating skeletons for instances that eventually were prevented from being rendered due to being LODed out. Added an extra LOD check during culling and the FPS went to 25 with 1 thread and 82 with 8 threads, or 3.28x scaling. Scaling dropped due to a bigger percentage of the frame time being spent in single-threaded parts.
EDIT2:
Turns out I actually got GPU limited after the skeleton animation optimization at 8 threads. Reducing the resolution a bit under 1920x1080 gave me an FPS of 26 with 1 thread and 89 with 8 threads, which equals 3.42x scaling like before!
Found a bug in my test program (not the engine) which switched around the LOD models, so the low-resolution models were being used up close and for distant instances the high-resolution models were used, cutting my FPS by 1/3rd⦠>___<
Finally finished all my work for my internship interview, now I just have to await their decision! Iām currently relaxing and not even touching a computer⦠besides this one. Oops.