freenode/#shirakumo - IRC Chatlog
Search
8:09:59
Colleen
reader.tymoon.eu/article/384 Website (XHTML), Title: The Road Ahead - June Kandria Update - 妖怪世捨て人
8:37:25
Shinmera
In Kandria I have a 'chunk'. A 'chunk' is a representation of a layered tile map. The layers it represents need to be drawn in the right order, and other entities need to be drawn /between/ those layers
8:38:20
Shinmera
Right now, (and I hate this), the player is a member of the chunk, so that the chunk can control the proper draw order.
8:43:54
Shinmera
I guess my question is: how would this scenario be handled in a situation where the scene graph is flattened into a draw sequence.
8:44:16
Shinmera
or rather, how would this be handled if I /don't/ want the player to be a part of the chunk
8:56:33
SAL9000
Shinmera: is it just the player (or is it other entities too), and will there be multiple "insert" locations in the draw order?
10:18:24
Shinmera
there's other entities too, there might need to be entities between other layers, too.
10:20:05
Shinmera
one idea is to split the chunk itself up, but that causes problems because it needs to be modified as if it were one (eg move the chunk somewhere)
10:20:28
Shinmera
though maybe that's not so bad? having each layer be separate would allow you to only need additional layers where necessary.
11:00:34
Shinmera
at the root of the scene graph, install one container that keeps separate sequences for each physical layer in the scene. entities are entered into the appropriate sequence depending on which layer they belong to. the chunk is split up into several layer entities that keep references to each other, so that moving or resizing one can affect the others
11:00:50
Shinmera
when flattening the scene graph into an action sequence, the container can then preserve the proper order.
12:33:33
Shinmera
though that already happens kinda sorta out-of-band in Trial, just with automated hooks in the scene graph machinery to register handlers.
12:43:21
SAL9000
Shinmera: Might make sense to have a protocol representing ordering between renderables? "layer X must be before layer Y" and "player must be after layer Z"
12:54:45
Shinmera
since the layer an object belongs to is often dynamic, stitching the ordering together sounds very cumbersome
12:56:39
Shinmera
if you force it to be static (ordering via class) it's easy since you could have a generic function that represents the order
12:57:07
Shinmera
but if it has to be per-instance, having the user state the ordering seems like it'd be a ton of boilerplate
13:01:44
Shinmera
Maybe it would work better with a 'depends-on' kinda logic, where objects can state dependencies on actions performed by others
13:16:39
Shinmera
you might have stuff where an entity requires the transforms established by another, but does not depend on that other entity being drawn first
13:46:04
Shinmera
for everything /except/ the transform hierarchy, a flat sequence seems to be the best thing
13:46:44
Shinmera
okey, so these are the contexts in which entities are used that I've identified so far:
13:48:19
Shinmera
Now, 2 and 3 are independent and can be done in external structures for the most part.
13:50:30
Shinmera
I mean you could do transforms and not render anything but there's no real point to that.
13:51:04
SAL9000
It means you can have your topo-sort dependency order, with each object's rendering depending on its own transform, and add whatever extra dependencies on top of that
13:51:39
Shinmera
ah, no. What I mean by transforms are things like: a car is made up of a chassis and wheels, they have different relative positioning to the car, but the car should move as a whole.
13:52:06
Shinmera
so the car establishes a transform context in which the wheels and chassis are rendered.
13:53:49
Shinmera
like, whenever you want to render x you'd have to go to the root and traverse downwards to compute the full matrices
13:54:00
Shinmera
or you'd have a separate pass where you compute the matrices and then save them for rendering?
13:56:12
Shinmera
one of the ideas that sounded the most promising to me so far was that the scene graph (used purely for transform context encoding) would be flattened into something with explicit calls to establish and tear down the context around 'groups' of entities.
13:58:42
Shinmera
anyway, to explain my idea a bit clearer: a hierarchy of A->(B C D),E->(F->(G)) would become something like: start-a,b,c,d,end-a,start-e,start-f,g,end-f,end-e
13:59:12
SAL9000
I'm trying to see if there's a way to slice this which allows a clean protocol for handling render ordering
13:59:49
Shinmera
in this scheme the ordering would be dependent on the way the entities are present in the tree.
14:00:39
SAL9000
and you have a scene graph already, you're not introducing one just for this, right?
14:01:23
Shinmera
I honestly don't know what the industry means by a scene graph entirely, but I do have a thing that allows you to nest objects, with a root name map to access named objects.
14:02:16
SAL9000
The notion of render order, still, can be specified partial ordering -- this must render before/after that
14:03:57
Shinmera
I suppose it could, though it would massively complicate the flattening, since it would have to keep track of the context regardless of the position in the resulting draw sequence.
14:04:21
Shinmera
The other question is whether it makes sense to ask for things to be rendered interleaved with things outside their transform context.
14:07:05
Shinmera
sure, though now you're wasting like potentially a 4k texture x layers of texture memory.
14:08:40
SAL9000
going the other way, do layer-graph flattening -- find the minimum number of layers required for each (sub)entity
14:09:20
Shinmera
Also, note, while one use case for me right now is that I have a 2.5D game, I'm designing things for 3D applications too.
14:10:05
SAL9000
Right. I started from a 2.5D perspective (conflating Z = layer) but that doesn't invalidate *everything*, just that conflation
14:10:23
Shinmera
as in, in a 2D game you're going to know ahead of time how many layers you'll afford
14:10:43
Shinmera
and in a 3D game the 'layers' (like solids and transparents) are even more explicit.
14:12:16
Shinmera
so you typically render them in an entirely separate manner (and thus a separate render pass as trial calls it)
14:13:35
Shinmera
maybe, though the typical approaches these days (when I last looked into it) just had a special rendering approach that didn't require any sorting or cutting.
14:14:27
SAL9000
I remember reading something about a trick that let you do sort+cut for semitransparent voxels
14:14:59
Shinmera
I don't disagree that it would be good if a pass could potentially reorder the draw calls of entities.
14:15:45
SAL9000
and that can be done "easily" by doing absolute transforms, but that means storing the transforms
14:16:19
Shinmera
The other approach would require tracking the context and re-establishing it if the entity leaves the context.
14:18:35
SAL9000
you can still flatten, but that doesn't "solve" the out-of-context layering, does it?
14:19:24
SAL9000
maybe cache the calculated transform instead -- leave the transform-cache slot unbound unless used
14:21:44
Shinmera
to be clear, what I'm imagining right now is this: For my 2.5D game, the scene graph root contains a container that maintains explicit layers into which actual game entities are inserted as appropriate. During flattening the layer order and order within layers is preserved. Transform context is only established for entities within a layer, for example if the player is carrying a light source or something.
14:23:03
Shinmera
for a 3D game with the example of separating solids from transparents, there's no explicit layering in the graph, but separate rendering passes each flatten the graph, only including draw calls for entities they care about respectively, but leaving the hierarchy intact.
14:23:48
SAL9000
layer transforms are only allowed to increase the layer (defer rendering), never decrease it
14:25:08
SAL9000
only one flatten pass, and each transform which has a non-zero layer axis caches the absolute value of its non-layer axes (for its children)
14:30:19
Shinmera
as in, the precomputed order would be as before, but the system would then push deferrals onto a queue, ignore the order as was precomputed, and then perform them later?
14:31:50
Shinmera
A->(B C D),E->(F->(G)) results in AOT sequence start-a,b,c,d,end-a,start-e,start-f,g,end-f,end-e
14:32:33
Shinmera
now let's say during execution of this sequence, we notice that C should be deferred
14:32:59
Shinmera
So we ignore C's draw call, save the transform at point, push C onto stack, and then perform the draw call after end-e
14:33:36
SAL9000
Yep, C's transform gets saved into its transform-cache slot, C gets pushed onto a stack and after end-e, C is performed
14:34:22
SAL9000
You might need a stack-of-stacks or something to deal with total-layer-transform > 1
14:35:08
SAL9000
idea being that if, say, A *also* has layer-transform +1, then C has total-layer-transform = 2
14:36:17
SAL9000
This only makes sense if you might want to defer whole groups of objects (e.g. A) as opposed to leaf objects
14:36:59
SAL9000
The transform-cache slot, stack, etc. only occurs once -- at A -- rather than 3 or 4 times (B C D or A B C D)
14:37:37
SAL9000
might be more clear as 'start-e start-f g end-f end-g START-A b d END-A C' where uppercase = cached
14:37:55
Shinmera
well if we use the dependency reordering with context tracking the system could easily recognise adjacent groups and merge them.
14:39:12
SAL9000
yep. If my assumption is correct (layer transforms containing 'many' objects) then optimization like that would help but shouldn't be "required" for this to work OK
14:44:19
SAL9000
what I have is a custom generational copying GC that hates my guts, a custom runtime linker and a 15-year-old compiler frontend
14:45:03
SAL9000
all of this on Windows + MSVC, which excludes a lot of nice tools too (valgrind, etc.)
14:45:44
SAL9000
I want to try building with clang + msvc-compatible mode at some point, but msys is "lol no" because we use all the Windows-specific APIs
14:47:34
SAL9000
yep. It is a lot of actual fun most of the time, though, when I'm not THIS deep into the guts
14:47:54
SAL9000
not many places would pay me to play with this kind of tech (custom language, custom incremental compiler, etc.)
14:56:40
SAL9000
I'm trying to clean up the parts I touch, but usually "no, we don't have time for a major refactor, JUST GET THE JOB DONE!!"
14:56:59
Shinmera
I keep going back and forth between deciding whether it's worse to have to debug someone else's mess or know that it's all your own fault.
14:57:44
SAL9000
It would legitimately be a major refactor... "custom C prepreprocessor" does NOT help there.
14:58:47
SAL9000
custom preprocessor written by my boss ~15 years ago, in pure C, in like 3 days and never touched since
14:59:21
SAL9000
nice features like macros with keyword/body arguments, etc., but the code is a steaming pile of segfault that dies when you look at it wrong
15:36:58
Shinmera
Writing a GCC-alike C preprocessor has been something I've considered doing many times
16:31:01
Shinmera
you can get away with not doing it most of the time, but yeah, depends on how much you want to support.
16:32:24
selwyn
i've got on my to do list writing a compatibility library for 3b-openvr, which wouldn't be a huge task
16:33:12
selwyn
but since its value is close to zero while i have nothing to deploy, i'm forcing myself to hold back on it and concentrate on more relevant things
16:38:37
selwyn
a c library that wraps the calls to openvr that pass structs by value, in order to remove the cffi-libffi dependency
16:41:45
selwyn
anyway, that's part of my attempt to work on things that are genuinely interesting as opposed to being sidetracked by nice technical things that don't mean a lot by themselves
17:09:46
Shinmera
not surprised at all given how shit the funding situation is in Switzerland though.
17:10:45
Shinmera
not a lot of offers, especially for games, and those that exist don't have a big budget.
17:12:23
Shinmera
Supposedly any single state in germany offers more funding for games than switzerland.
17:13:53
selwyn
if i go down the route of securing funding, i'm thinking of moving somewhere else in the uk and trying to get a regional grant
17:15:48
selwyn
there are lots of small towns and regions that are trying to become 'tech hubs' or the 'next silicon valley'
17:16:39
selwyn
in my opinion, they are a little overambitious, but if the funding is there and i can get it then why not