Having read the FAQs regarding the DX9 render window (faq multiscreen), I’m still puzzled as to why some patches (particularly involving GPU particles and splines) do not render properly on a second window (they go black, and from then on the renderer does not recover). At first I thought it was a memory limitation on my laptop’s graphics card (an nVidia Quadro 1000M), but having tested on a Quadro K5000, the problem persists. Is this something specific of certain GPU-accelerated shaders? (ex: splinesgpu, particlesgpu-shader-library)..)
i’d guess it is nothing more specific than just a nasty bug that needs fixing. as always in order to be able to do so we’d need a step-by-step description of how to reproduce the problem with the smallest possible patch.
Take any patch of the example above (contribution:splinesgpu), open it on the main monitor. Drag the render window to a second monitor - renderer goes black. Bringing it back to the main monitor does not recover the problem and vvvv needs to be restarted.
well i believe you that. but now someone has to debug that problem. ie. first find the smallest possible case to reproduce the problem. and since you’re at it you could start with that. the simpler the demo that shows the problem the higher the chances we can fix it.
That’s fair enough ;)
Unfortunately this happens in fairly complex patches, but I’ve chosen a version of a B-Spline in SplinesGPU by @woei for monitoring the issue. Perhaps the bug is in some effects or shaders, I do not know…
B-Spline PhongDirectional GPU.zip (10.6 kB)
@yuri2k: Just hit the update pin on Spline (EX9 Mesh) module and the renderer will show splines again. Or/Then save the patch with the renderer in the second output and restart vvvv…
… for me it is working in this way
There you go, this problem been there for ages, had that with particleGPU ages ago.
You should have a grid, now move Renderer to another screen and poof, disappeared.
VertexBufferProblem.v4p (5.2 kB)
Thank you, all. I’m afraid my vvvvocabulary is still limited :-/. Hope it finds its way to a fix in the future.
ok, so but that is kind of by design.
what would be the desired behaviour? we cannot simply do “autoapply on new device” because e.g. onLoading a patch i may not want it to autoapply as i’d want to delay applying deliberately. so we’d need a new Apply on DeviceChange for both VertexBuffer and Mesh. and what would its default be? probably ON. thoughts?
Issue is when you move a standard mesh (box/sphere), shader, texture, you update them automatically to the new device.
In case of vertexbuffer you don’t, so behavior is rather non consistent, and therefore confusing.
Anyway if a resource is required by a device, it should be loaded on that device. If we want to delay load, we already can set the Apply pin manually (without setting it to “OnOpen”).
newly created vertex buffer and mesh join nodes will recreate the resource when device changes. this is done by a new pin “Apply On Device Change”, which is by default set to true for new nodes and false for nodes in old patches and is only visible in the inspektor.