freenode/#shirakumo - IRC Chatlog
Search
6:31:44
gingerale
Yeah, that sounds like a tough issue. I feel most existing things do caching as I've recall seeing them fail every now and then. With drawing I think performance is important though, so the state management should be worth it.
6:32:54
gingerale
I've been doing a lot of code optimisation at work for our darn web app. So much of it is just managing when to trigger the browser's layouting process.
6:38:06
gingerale
Like a case is where in the text editor tabulators need to have their widths exact to the designed stopping points. So they're preformatted span elements and each one in a paragraph needs to be calculated before the next one. Each of these then cause a layout process (not the draw process!) in the browser and that takes most of the computing time for them.
6:59:44
Shinmera
I think what needs to be done is have almost everything retained, and have a specific update step that is automatically triggered when a component needs to be refreshed when part of its data is changed
7:00:27
Shinmera
so something like if the component is marked for render, on next render it will call an update function that can change the retained properties of its shapes.
7:28:23
Shinmera
One problem might be that, at the point you arrive at the update function, the information on what exactly needs to be changed might be lost
7:28:54
Shinmera
so you would end up having to recompute everything even if it's not strictly necessary
10:50:32
Shinmera
If you hit the section key (top left corner of the keyboard) it'll show debug info in the top left, including the measured framerate
10:50:49
Shinmera
It's possible you're already running at refresh rate if your compositor enforces it.
10:54:24
selwyn
my problem is that everything hangs if I request the HMD pose information on every frame
10:54:30
selwyn
hence this hacky workaround https://github.com/selwynsimsek/trial-vr/blob/master/src/rendering.lisp#L46
10:54:30
Colleen
github.com/selwynsimsek/tri... Website (HTML), Title: trial-vr/rendering.lisp at master · selwynsimsek/trial-vr · GitHub
10:55:16
Shinmera
physics updates happen at lock-step, typically 100Hz, while rendering is unlocked.
10:56:01
Shinmera
you can change the physics delta time by passing :delta-time ... to your MAIN initargs.
10:57:35
Shinmera
Anyway, isn't there a callback thing you could use instead to get the pose when it changes?
11:01:08
Shinmera
For one, you can do (3d-matrices::%mat4 matrix) directly. The standard mat4 will copy to avoid sharing.
11:02:04
Shinmera
For two, having to run vr-system, vr-compositor, and especially wait-get-poses seems suspicious
11:02:20
Shinmera
Are you sure you have to call these for every physics step, and especially synchronously, or..?
11:03:20
Shinmera
For three there might be a call that can copy the matrix into the array directly by passing the pointer to the VR library.
11:06:20
selwyn
wait-get-poses is what calculates the HMD pose and should properly be called in the render loop per the API docs
11:09:31
Shinmera
the wait is what makes me suspicious. It seems real bad to have to sync in your hot loop
11:13:34
selwyn
so here are the docs: https://github.com/ValveSoftware/openvr/wiki/IVRCompositor_Overview
11:13:34
Colleen
github.com/ValveSoftware/op... Website (HTML), Title: IVRCompositor_Overview · ValveSoftware/openvr Wiki · GitHub
11:15:50
Shinmera
Which wants an "expected time until flush", which currently isn't info that's available in Trial
11:17:05
Shinmera
WaitGetPoses seems to do the same as the above, just also make the current application focused. So you might have to call something else to get the focus on the app when you start up
11:29:12
selwyn
3b's openvr demo does call wait-get-poses in the render loop and it certainly is higher than 12fps. so it's still a mystery
11:35:36
Shinmera
Also, doing expensive stuff in tick is bad because trial enforces "real time" on it by having it lock-stepped. Meaning if your operation starts lagging it'll call tick more frequently to try and make up for the lag.
11:36:00
Shinmera
since the pose is only important for the render, you should be able to update it in the render step.
11:39:46
Shinmera
actually, for the pose update make sure to call it in a render method, not a paint method.
11:56:14
selwyn
i had previously tried doing it in a paint method specialised on the compositor-render-pass, perhaps that was the problem
11:59:17
Shinmera
als, instead of copy-pasting the render aound there, you should just call gl:viewport in paint-with for the eye passes.
12:11:59
Shinmera
Whenever I work on this I immediately have to think about what I could do to batch update and reduce GL calls, but so far I have not been able to find anything satisfactory.
12:38:52
selwyn
only part of the framebuffer is being rendered to https://usercontent.irccloud-cdn.com/file/Pj132Fqf/Screenshot%20from%202019-10-20%2013-36-03.png