freenode/#shirakumo - IRC Chatlog
Search
20:15:18
|3b|
Shinmera: in my code i'm trying to get rid of "scene graph" and split out the specific uses into specific things
20:16:56
|3b|
like "transform hierarchy" and "x belongs to y" tend to have different amounts of detail, like X is a skinned mesh, so there are 5 or 6 nodes between X and Y, or y has a bunch of components due to multiple shaders, but all with same transform
20:17:35
Shinmera
my idea right now is to still have a scene graph, but only use it for the transform hierarchy.
20:17:35
|3b|
and also i want to just dump the transform hierarchy to GPU for updates as a big blob of matrices, so i might as well store it that way :)
20:18:08
|3b|
oh yeah, the other traditional use for a scene graph was property inheritance, which seems relatively uncommon these days
20:18:14
Shinmera
when combined with a shader pipeline, the scene graph then gets flattened into a sequence of 'actions' for each pass, only retaining the actions relevant to the pass
20:19:11
|3b|
but these days, each node would just have its own material, or be combined into a single mesh
20:20:46
Shinmera
I was thinking about stuff like: a car is made outta a chassis, wheels, and some lights. All of them need a tree of transforms to be properly placed, but only some of them should be included or applied for certain passes.
20:21:11
Shinmera
so there needs to be a way for each pass to be selective about which entities it cares about, while retaining the transform hierarchy
20:23:51
|3b|
yeah, i think "lists of things with certain properties" was another of the things i was thinking of to replace parts of scene graph
20:25:33
|3b|
ACTION never really got to a good answer for all of it, so might insight is mostly just "the scene graph concept limits your thinking and isn't a great fit for modern GFX, so think about the goals separately without the scene graph"
20:25:48
Shinmera
right now my idea is to transform something like ((a . b c) d) into (begin-a draw-a draw-b draw-c end-a draw-d)
20:26:22
Shinmera
and a pass that only cares about c would have a sequence like (begin-a draw-c end-a)
20:27:57
Shinmera
the structure would then retain references to where it begins/ends in the sequence in order to efficiently enter or remove things.
20:31:07
Shinmera
I actually really wonder how commercial engines deal with managing the shader pipeline
20:32:56
Shinmera
like I know Unity has a very rigorous pipeline and customising it is still (?) a beta thing taht's super involved
20:33:23
Shinmera
so obviously if you don't have to anticipate customisation for that you can just pick a fixed pipeline more or less and be done with it.
20:35:38
|3b|
not having good answers for this stuff is probably one of the reasons i get sidetracked writing other libs instead of writing an engine/game :/
20:37:25
Shinmera
yeah. I'm pushed to work it out now because things in Kandria are such a fucking mess I can't stand it
20:39:28
|3b|
(both in the sense of suggesting concrete use cases, and in the sense of having something concrete to get back to working on after solving the problems)
20:40:03
|3b|
ACTION 's "make a game" entry on the stack below "make an engine" is still fairly vague
20:40:46
Shinmera
Seeing how quickly other people are able to progress their games makes me regret making my own crap from scratch
20:41:54
|3b|
ACTION can tell that i'd probably still not be making much more progress either way, so doesn't have that problem too much :p
20:42:43
|3b|
particularly when i look at other people who make their own entire toolchain in C and still make more progress than me
20:43:56
|3b|
ACTION tries to just accept it, and keep a wide variety of things to possibly work on (including lots of non-code things)
20:44:46
|3b|
(having a specific project, and people watching/waiting for it makes that a bit harder though)
20:47:53
|3b|
ACTION is making progress on new binpacking code, so hopefully can finish that and get back to msdf soon :)
20:49:09
|3b|
ACTION will also try to improve options for runtime bin packing, for use with on-demand sdf generation/caching
20:50:26
|3b|
ACTION was thinking about that as a potential target for runtime bin packing, where instead of trying to pack things relatively squarely, it would expand in blocks of NxN inside an MxM texture, for use with sparse texture
20:51:12
|3b|
basically it's MMU for textures, you can for example allocate a 16kx16k texture, and then only actually have texture data for the lowest mipmaps, and a few 256x256 blocks that happen to be close to the viewer
20:52:07
|3b|
also useful for things like "allocate a 2d texture array of 1k textures, and only actually fill a few of them"
20:52:48
|3b|
which can be useful for reducing texture binds, if you have an array binding for each combination of size/format instead of a binding per texture
20:54:19
|3b|
and probably not worth adding just for fun unless you are doing mostly r&d engine like i am
20:54:55
Shinmera
I tend to be complete about features when I'm implementing something, but I don't go out of my way for it