Thursday, May 23rd, 2024

Time	Event
1:14a	The Russian Video Game Engine Wanted to say something russophobic, but surprisingly it is one of the more clean looking exhibits, with an entity system similar to Unity: https://github.com/storm-devs/storm-engine/blob/develop/src/libs/core/include/entity.h https://github.com/storm-devs/storm-engine/blob/develop/src/libs/core/include/attributes.h Sometimes they treat several distinct agents as a single entity, individual entities are not lightweight enough: https://github.com/storm-devs/storm-engine/blob/develop/src/libs/sailors/src/sailors.h So it is not a pure entity system. but I guess the Russians refactored their engine heavily before making it public. Would be interesting to see their vintage code circa 2000. Another source base worth checking is Jurassic Park Trespasser, that was the Crysis of the 1998, supporting stuff like normal maps. Yet their entity is rather standard: https://github.com/OpenTrespasser/JurassicParkTrespasser/blob/master/jp2_pc/Source/Lib/EntityDBase/Instancer.hpp They have a dedicated CEntity class, but it is just piles a few methods on top of CInstance in addition to mostly unused global id. https://github.com/OpenTrespasser/JurassicParkTrespasser/blob/master/jp2_pc/Source/Lib/EntityDBase/Entity.hpp So a final entity will be constructed by a chain of inheritance CAnimal -> CAnimate -> CEntity -> CInstance -> CPartition, CFetchable CPartition would be a visual component in ECS, while CFetchable would be a serializer component. Obviously all these classes imply appropriate virtual methods, which have to be supplied along the way in a haphazard way of true OOP spaghetti code. Then again, the main feature of this game was its physics and dynamic animation system. Current Mood: amused Current Music: Clan of Xymox - Leave Me Be (4 Comments | Comment on this)
12:21p	Writing a Software Renderer With multicore CPU, one has to organize the rendering somehow, so the cores can work without any locking. Apparently the technology to use is called tiling. Basically the framebuffer in broken into 32x32 tiles, and the objects are then assigned to the tiles they overlap. Now CPU threads can be assigned sets unique tiles. I.e. if your tile overlaps just a few voxel models, you don't need to include the rest into your BVH. Here are a lecture and an article on that: https://youtu.be/i3jRPWx21_A?t=2405 https://en.wikipedia.org/wiki/Tiled_rendering these talk about triangles and rasterization, but raycasting needs these even more. That is important when you have a ton of voxel entities, since storing, rendering and modifying a single large octree is expensive. So you typically break your big octree slab into 32x32x32 chunks, inside which 16bit offsets are valid. I kinda began transitioning my voxel engine to tiled rendering, but just breaking the octree into chunks gave enough speed on my vintage CPU. But yeah, you do tiled BVH on a GPU and render only the actually dirty tiles while using the LoD versions for fast moving ones, I do expect lightning editing speeds even for enormously huge models (think 3**(2**16)). Current Mood: amused (6 Comments | Comment on this)

<< Previous Day

2024/05/23 [Calendar]

Next Day >>