freenode/#shirakumo - IRC Chatlog
Search
16:55:46
Shinmera
|3b|: Do you have any thoughts on how to implement the caching logic for an immediate UI? I'm struggling to think of a good way to manage GL resources-- making sure they don't just get allocated out the wazoo and/or never deallocated.
16:58:32
|3b|
not thought that far, aside from having some sort of scoped resource manager thing that can automatically deallocate a bunch of things at once by name or scope (and with a wrapper with validity tracking for the resources, so they can error if used after deallocation)
16:59:51
Shinmera
I'm asking because I don't see the situation being much better in a retained mode UI
17:00:26
|3b|
yeah, seems like retained-mode just makes it easier to tell what can be cached / for how long
17:01:33
Shinmera
Even then it's hard to keep track of stuff. Like, if lots of things are drawing line strips... should I allocate fixed VBOs for everything, and hope there's not too many to blow me up, or should I just stream it every time?
17:02:49
|3b|
ACTION has some vague thoughts about having a fairly big VBO with 'automatic' memory management/GC inside it, but probably will start with just a bunch of small VBOs
17:04:41
|3b|
though wouldn't have the liveness tracking of a real GC, mostly just compacting it to avoid fragmentation
17:05:07
Shinmera
Yeah, but even then I shudder to think of this blowing up in someone's face and trying to debug it.
17:05:13
|3b|
GPU have lots of bandwidth, so that should be reasonable fast, leaving only tracking/updating offsets on host side to deal with
17:07:06
|3b|
i'm just talking about moving parts of a buffer around inside that buffer (or from 1 buffer to another), all on GPU
17:10:12
|3b|
ACTION would probably lean towards just rendering windows to an FBO, and caching that, ideally with incremental updates
17:11:11
Shinmera
Caching circles and rectangles is easy enough, but text, line strips, beziers, gradients (?) etc would be more tricky.
17:11:34
Shinmera
Not even sure what I'd do for gradients. stencil the shape then use a rect or something?
17:13:26
Shinmera
Yeah, gone are the days of only being able to afford memory for one screen at a time.
22:04:41
selwyn
Hacking lisp at the beach on my massive portacle companion cube (in VR) https://usercontent.irccloud-cdn.com/file/Af9MSRze/out.png
22:06:33
selwyn
this is the view from VR. the portacle window displayed on the front of that cube is connected to a REPL which is itself running the whole VR experience using trial and 3b-openvr
22:08:41
selwyn
the idea is that the developer has access to a 'VR-REPL' from inside VR which lets one code interactively to alter the VR environment while one experiences it, allowing for great freedom
22:13:18
|3b|
cool, that was best solution i found too, though hopefully can figure out something that works on ms windows too at some point
22:13:30
selwyn
using Xvfb, fluxbox, and vncviewer to get a copy on the desktop. was surprised by how robust it was
22:14:22
|3b|
ACTION was just reparenting a window directly, had some problems convincing emacs to behave though, so ended up using an xterm and running emacs in that
22:14:51
selwyn
Xvfb can make x windows available via shared memory which can be sent to gl-tex-image-2d, so the memory is never copied into the lisp process
22:16:03
|3b|
https://www.youtube.com/watch?v=nbY-meOL57I was as far as i got with that setup, don't think i ever used it in VR since there wasn't as much linux VR support at that point :/
22:16:03
Colleen
www.youtube.com/watch?v=nbY... Website (HTML), Title: debugging from inside the code being debugged - YouTube
22:20:54
|3b|
though not sure about window management in that case, switching between keyboard and controller would probably be more annoying than keyboard+mouse, and not sure if keyboard would be convenient for window management in 3d
22:21:19
|3b|
though maybe it would have enough space that it wouldn't require too much active management, dunno
22:22:28
|3b|
ACTION should probably stop reading about mipi csi cameras and work on my 2d code if i want to ever actually get back to VR :p
22:22:56
selwyn
i am thinking of using a voice coding system to free up my hands entirely for the controllers
22:25:06
selwyn
i have some changes to 3b-openvr which include an updated library version and shipped binaries (per OpenVR's instructions) - would you be interested in a PR?
22:25:40
|3b|
i think i saw that, PR might be nice, though looked like there was some extra stuff in your repo last i saw
22:26:20
|3b|
not sure i'd want binaries included in the repo though, possibly better as a separate repo
22:27:17
selwyn
one could glue LEDs to things and using cameras mounted on tracker stations to figure out object position and orientation. still a lot of work though
22:32:54
|3b|
not sure what difference is for the linux .so, maybe lib/ is the dbg version? looks same size at least
22:35:26
selwyn
so my experience so far with VR in linux is that steamvr/openvr can be temperamental but its quite feasible
23:13:19
selwyn
i run sbcl from inside the steam runtime and everything works out fine including wrt opengl