[quote="helifax"]Both Minecraft and ID5 use multiple frameBuffer objects and buffers so I need to duplicate these as well I guess... and this is the next big step;)) I need to think on how I am going to tackle this (code-wise) so is optimum and hassle-free and easy maintainable;))[/quote]
Here again, I'm not well versed on OpenGL, but maybe this is helping.
For the framebuffer objects and other buffers, I'm pretty sure you do not need to duplicate those.
The main reason is that all of that stuff is the same regardless of eye position. Take for example the two basic building blocks of vertex buffers, and texture maps. Those have to be assigned to the GPU using calls, but are assigned as data objects to be used by drawing, not actually drawn. The shaders do the actual drawing using those as input.
Vertex buffers are just a list of vertices that build the 3D model, the wireframe. This would not change based on eye position, because it's the 3D model of the world, and is the same for both eyes. Slightly different viewpoint, but sort of the same as rotating all around a 3D model.
The texture maps are painted onto the wire frame, and are also the same data for either eye. The angle they display at might be different, but the raw data is the same in each case, just like the vertices.
So, unless I'm missing something, or we're talking about different buffers, I don't think any of that data needs to be duplicated.
helifax said:Both Minecraft and ID5 use multiple frameBuffer objects and buffers so I need to duplicate these as well I guess... and this is the next big step;)) I need to think on how I am going to tackle this (code-wise) so is optimum and hassle-free and easy maintainable;))
Here again, I'm not well versed on OpenGL, but maybe this is helping.
For the framebuffer objects and other buffers, I'm pretty sure you do not need to duplicate those.
The main reason is that all of that stuff is the same regardless of eye position. Take for example the two basic building blocks of vertex buffers, and texture maps. Those have to be assigned to the GPU using calls, but are assigned as data objects to be used by drawing, not actually drawn. The shaders do the actual drawing using those as input.
Vertex buffers are just a list of vertices that build the 3D model, the wireframe. This would not change based on eye position, because it's the 3D model of the world, and is the same for both eyes. Slightly different viewpoint, but sort of the same as rotating all around a 3D model.
The texture maps are painted onto the wire frame, and are also the same data for either eye. The angle they display at might be different, but the raw data is the same in each case, just like the vertices.
So, unless I'm missing something, or we're talking about different buffers, I don't think any of that data needs to be duplicated.
Acer H5360 (1280x720@120Hz) - ASUS VG248QE with GSync mod - 3D Vision 1&2 - Driver 372.54
GTX 970 - i5-4670K@4.2GHz - 12GB RAM - Win7x64+evilKB2670838 - 4 Disk X25 RAID
SAGER NP9870-S - GTX 980 - i7-6700K - Win10 Pro 1607 Latest 3Dmigoto Release Bo3b's School for ShaderHackers
[quote="Pirateguybrush"]I only ever understand about 16% of what goes on in this thread, but it's consistently interesting. :)[/quote]
:) I know you have Broken Age. Did you had time to try out the new wrapper? From the previous page?
Thx in advance;))
Pirateguybrush said:I only ever understand about 16% of what goes on in this thread, but it's consistently interesting. :)
:) I know you have Broken Age. Did you had time to try out the new wrapper? From the previous page?
Thx in advance;))
1x Palit RTX 2080Ti Pro Gaming OC(watercooled and overclocked to hell)
3x 3D Vision Ready Asus VG278HE monitors (5760x1080).
Intel i9 9900K (overclocked to 5.3 and watercooled ofc).
Asus Maximus XI Hero Mobo.
16 GB Team Group T-Force Dark Pro DDR4 @ 3600.
Lots of Disks:
- Raid 0 - 256GB Sandisk Extreme SSD.
- Raid 0 - WD Black - 2TB.
- SanDisk SSD PLUS 480 GB.
- Intel 760p 256GB M.2 PCIe NVMe SSD.
Creative Sound Blaster Z.
Windows 10 x64 Pro.
etc
[quote="bo3b"][quote="helifax"]Both Minecraft and ID5 use multiple frameBuffer objects and buffers so I need to duplicate these as well I guess... and this is the next big step;)) I need to think on how I am going to tackle this (code-wise) so is optimum and hassle-free and easy maintainable;))[/quote]
Here again, I'm not well versed on OpenGL, but maybe this is helping.
For the framebuffer objects and other buffers, I'm pretty sure you do not need to duplicate those.
The main reason is that all of that stuff is the same regardless of eye position. Take for example the two basic building blocks of vertex buffers, and texture maps. Those have to be assigned to the GPU using calls, but are assigned as data objects to be used by drawing, not actually drawn. The shaders do the actual drawing using those as input.
Vertex buffers are just a list of vertices that build the 3D model, the wireframe. This would not change based on eye position, because it's the 3D model of the world, and is the same for both eyes. Slightly different viewpoint, but sort of the same as rotating all around a 3D model.
The texture maps are painted onto the wire frame, and are also the same data for either eye. The angle they display at might be different, but the raw data is the same in each case, just like the vertices.
So, unless I'm missing something, or we're talking about different buffers, I don't think any of that data needs to be duplicated.[/quote]
Hmm, I do think I need to duplicate some of them:
By default you have one framebuffer glBindFramebuffer(GL_FRAME_BUFFER, 0).
Most apps generate additional GL_FRAME_BUFFERS (1,2,etc) to draw certain elements of the final picture in them.
Then at the end they switch back to framebuffer 0 and copy the content from those buffers.
And swap the buffers.
Now If I only duplicate GL_FRAME_BUFFER_0 (for left + right eyes) I will only get stereo on what is actually glDrawXXXX in the GL_FRAME_BUFFER_0.
So if I have glDrawXXX on GL_FRAME_BUFFER_2 basically I need to duplicate these buffers as well so I can render those elements in stereo as well.
All the other types of Buffers and VAOs, VBOs don't need a duplication. Don't you agree ?
helifax said:Both Minecraft and ID5 use multiple frameBuffer objects and buffers so I need to duplicate these as well I guess... and this is the next big step;)) I need to think on how I am going to tackle this (code-wise) so is optimum and hassle-free and easy maintainable;))
Here again, I'm not well versed on OpenGL, but maybe this is helping.
For the framebuffer objects and other buffers, I'm pretty sure you do not need to duplicate those.
The main reason is that all of that stuff is the same regardless of eye position. Take for example the two basic building blocks of vertex buffers, and texture maps. Those have to be assigned to the GPU using calls, but are assigned as data objects to be used by drawing, not actually drawn. The shaders do the actual drawing using those as input.
Vertex buffers are just a list of vertices that build the 3D model, the wireframe. This would not change based on eye position, because it's the 3D model of the world, and is the same for both eyes. Slightly different viewpoint, but sort of the same as rotating all around a 3D model.
The texture maps are painted onto the wire frame, and are also the same data for either eye. The angle they display at might be different, but the raw data is the same in each case, just like the vertices.
So, unless I'm missing something, or we're talking about different buffers, I don't think any of that data needs to be duplicated.
Hmm, I do think I need to duplicate some of them:
By default you have one framebuffer glBindFramebuffer(GL_FRAME_BUFFER, 0).
Most apps generate additional GL_FRAME_BUFFERS (1,2,etc) to draw certain elements of the final picture in them.
Then at the end they switch back to framebuffer 0 and copy the content from those buffers.
And swap the buffers.
Now If I only duplicate GL_FRAME_BUFFER_0 (for left + right eyes) I will only get stereo on what is actually glDrawXXXX in the GL_FRAME_BUFFER_0.
So if I have glDrawXXX on GL_FRAME_BUFFER_2 basically I need to duplicate these buffers as well so I can render those elements in stereo as well.
All the other types of Buffers and VAOs, VBOs don't need a duplication. Don't you agree ?
1x Palit RTX 2080Ti Pro Gaming OC(watercooled and overclocked to hell)
3x 3D Vision Ready Asus VG278HE monitors (5760x1080).
Intel i9 9900K (overclocked to 5.3 and watercooled ofc).
Asus Maximus XI Hero Mobo.
16 GB Team Group T-Force Dark Pro DDR4 @ 3600.
Lots of Disks:
- Raid 0 - 256GB Sandisk Extreme SSD.
- Raid 0 - WD Black - 2TB.
- SanDisk SSD PLUS 480 GB.
- Intel 760p 256GB M.2 PCIe NVMe SSD.
Creative Sound Blaster Z.
Windows 10 x64 Pro.
etc
Just tried it out. Results:
Game launches, is 3d. However there appear to be missing textures, occasional broken shaders, and no mouse cursor. Getting about 1fps with SLI, or 60 without. The scene in Vella's house at the start was completely flat+depth. I don't know if that's just this particular scene though.
When I try it with the old version, it loads up your custom splash screen, and nothing else happens. Sits in task manager using about 1.5mb of ram, even after closing the splash screen. It's not selectable on the task bar. It did load once, but almost everything was black.
Just tried it out. Results:
Game launches, is 3d. However there appear to be missing textures, occasional broken shaders, and no mouse cursor. Getting about 1fps with SLI, or 60 without. The scene in Vella's house at the start was completely flat+depth. I don't know if that's just this particular scene though.
When I try it with the old version, it loads up your custom splash screen, and nothing else happens. Sits in task manager using about 1.5mb of ram, even after closing the splash screen. It's not selectable on the task bar. It did load once, but almost everything was black.
[quote="Pirateguybrush"]Just tried it out. Results:
Game launches, is 3d. However there appear to be missing textures, occasional broken shaders, and no mouse cursor. Getting about 1fps with SLI, or 60 without. The scene in Vella's house at the start was completely flat+depth. I don't know if that's just this particular scene though.
When I try it with the old version, it loads up your custom splash screen, and nothing else happens. Sits in task manager using about 1.5mb of ram, even after closing the splash screen. It's not selectable on the task bar. It did load once, but almost everything was black.[/quote]
That is very very strange... What version of the game are you using ? from Steam? I am wondering if it got patched or something... (since I am using A steam one but cracked so not updated in case they updated the game).
Also have you tried to delete the Shaders Folder and see if the SLI performance increases?
Pirateguybrush said:Just tried it out. Results:
Game launches, is 3d. However there appear to be missing textures, occasional broken shaders, and no mouse cursor. Getting about 1fps with SLI, or 60 without. The scene in Vella's house at the start was completely flat+depth. I don't know if that's just this particular scene though.
When I try it with the old version, it loads up your custom splash screen, and nothing else happens. Sits in task manager using about 1.5mb of ram, even after closing the splash screen. It's not selectable on the task bar. It did load once, but almost everything was black.
That is very very strange... What version of the game are you using ? from Steam? I am wondering if it got patched or something... (since I am using A steam one but cracked so not updated in case they updated the game).
Also have you tried to delete the Shaders Folder and see if the SLI performance increases?
1x Palit RTX 2080Ti Pro Gaming OC(watercooled and overclocked to hell)
3x 3D Vision Ready Asus VG278HE monitors (5760x1080).
Intel i9 9900K (overclocked to 5.3 and watercooled ofc).
Asus Maximus XI Hero Mobo.
16 GB Team Group T-Force Dark Pro DDR4 @ 3600.
Lots of Disks:
- Raid 0 - 256GB Sandisk Extreme SSD.
- Raid 0 - WD Black - 2TB.
- SanDisk SSD PLUS 480 GB.
- Intel 760p 256GB M.2 PCIe NVMe SSD.
Creative Sound Blaster Z.
Windows 10 x64 Pro.
etc
Been doing more tests...
Unfortunately most engine don't use just one set of Framebuffers. They render quite a lot in offscreen framebuffers and then just blit those buffers in the back framebuffer.
In order for the stereo you need to duplicate those framebuffers + all the textures attached to them. Here is very tricky because you don't know if a texture will be attached to a framebuffer or used somewhere else... + duplicating all the setting up & operations for the FBs....
You could end up allocating alot of buffers + textures very fast which are not used...
If you simply duplicate the draw calls and draw in the same offscreen framebuffer well you get stereo but unusable since the same buffer will have both eyes overlapped... I also noticed the nvidia driver getting very busy and the FPS going down all the way to 1fps in SLI configurations over time...
So while in theory this might be doable all the testing so far points out that is not...
So, the only viable option is to call the whole render loop a second time (so the same fb are used and reset) and the final output to be put in the right eye final framebuffer. Something like I am doing now but for the current frame rather than the next one... However so far I wasn't able to "make the jump" to the start of the drawing loop a second time in the same frame...
Just wanted to let anyone know:)
Been doing more tests...
Unfortunately most engine don't use just one set of Framebuffers. They render quite a lot in offscreen framebuffers and then just blit those buffers in the back framebuffer.
In order for the stereo you need to duplicate those framebuffers + all the textures attached to them. Here is very tricky because you don't know if a texture will be attached to a framebuffer or used somewhere else... + duplicating all the setting up & operations for the FBs....
You could end up allocating alot of buffers + textures very fast which are not used...
If you simply duplicate the draw calls and draw in the same offscreen framebuffer well you get stereo but unusable since the same buffer will have both eyes overlapped... I also noticed the nvidia driver getting very busy and the FPS going down all the way to 1fps in SLI configurations over time...
So while in theory this might be doable all the testing so far points out that is not...
So, the only viable option is to call the whole render loop a second time (so the same fb are used and reset) and the final output to be put in the right eye final framebuffer. Something like I am doing now but for the current frame rather than the next one... However so far I wasn't able to "make the jump" to the start of the drawing loop a second time in the same frame...
Just wanted to let anyone know:)
1x Palit RTX 2080Ti Pro Gaming OC(watercooled and overclocked to hell)
3x 3D Vision Ready Asus VG278HE monitors (5760x1080).
Intel i9 9900K (overclocked to 5.3 and watercooled ofc).
Asus Maximus XI Hero Mobo.
16 GB Team Group T-Force Dark Pro DDR4 @ 3600.
Lots of Disks:
- Raid 0 - 256GB Sandisk Extreme SSD.
- Raid 0 - WD Black - 2TB.
- SanDisk SSD PLUS 480 GB.
- Intel 760p 256GB M.2 PCIe NVMe SSD.
Creative Sound Blaster Z.
Windows 10 x64 Pro.
etc
[quote="helifax"]Been doing more tests...
Unfortunately most engine don't use just one set of Framebuffers. They render quite a lot in offscreen framebuffers and then just blit those buffers in the back framebuffer.
In order for the stereo you need to duplicate those framebuffers + all the textures attached to them. Here is very tricky because you don't know if a texture will be attached to a framebuffer or used somewhere else... + duplicating all the setting up & operations for the FBs....
You could end up allocating alot of buffers + textures very fast which are not used...
If you simply duplicate the draw calls and draw in the same offscreen framebuffer well you get stereo but unusable since the same buffer will have both eyes overlapped... I also noticed the nvidia driver getting very busy and the FPS going down all the way to 1fps in SLI configurations over time...
So while in theory this might be doable all the testing so far points out that is not...
So, the only viable option is to call the whole render loop a second time (so the same fb are used and reset) and the final output to be put in the right eye final framebuffer. Something like I am doing now but for the current frame rather than the next one... However so far I wasn't able to "make the jump" to the start of the drawing loop a second time in the same frame...
Just wanted to let anyone know:)[/quote]When I'm looking at the Vireio code, it seems like they handle this case by duplicating the offscreen buffer for each eye. Then, when it comes times to blit back to the backbuffer, they blit only to the proper eye from the proper buffer.
So, yes it would suggest you need to duplicate those buffers and draw calls, but it does not suggest that you need to do anything very tricky to make that work. They definitely do not duplicate the textures, those are used as a one-off to create the offscreen buffer, and once they are drawn they are done.
In DirectX I think these offscreen buffers are created with CreateRenderTarget. See for example:
[url]https://github.com/cybereality/Perception/blob/365d81ab54b18b426202bdbc16e986592eecf3d5/DxProxy/DxProxy/D3D9ProxySurface.cpp[/url]
Might be I'm misunderstanding the problem though.
helifax said:Been doing more tests...
Unfortunately most engine don't use just one set of Framebuffers. They render quite a lot in offscreen framebuffers and then just blit those buffers in the back framebuffer.
In order for the stereo you need to duplicate those framebuffers + all the textures attached to them. Here is very tricky because you don't know if a texture will be attached to a framebuffer or used somewhere else... + duplicating all the setting up & operations for the FBs....
You could end up allocating alot of buffers + textures very fast which are not used...
If you simply duplicate the draw calls and draw in the same offscreen framebuffer well you get stereo but unusable since the same buffer will have both eyes overlapped... I also noticed the nvidia driver getting very busy and the FPS going down all the way to 1fps in SLI configurations over time...
So while in theory this might be doable all the testing so far points out that is not...
So, the only viable option is to call the whole render loop a second time (so the same fb are used and reset) and the final output to be put in the right eye final framebuffer. Something like I am doing now but for the current frame rather than the next one... However so far I wasn't able to "make the jump" to the start of the drawing loop a second time in the same frame...
Just wanted to let anyone know:)
When I'm looking at the Vireio code, it seems like they handle this case by duplicating the offscreen buffer for each eye. Then, when it comes times to blit back to the backbuffer, they blit only to the proper eye from the proper buffer.
So, yes it would suggest you need to duplicate those buffers and draw calls, but it does not suggest that you need to do anything very tricky to make that work. They definitely do not duplicate the textures, those are used as a one-off to create the offscreen buffer, and once they are drawn they are done.
In DirectX I think these offscreen buffers are created with CreateRenderTarget. See for example:
[quote="bo3b"][quote="helifax"]Been doing more tests...
Unfortunately most engine don't use just one set of Framebuffers. They render quite a lot in offscreen framebuffers and then just blit those buffers in the back framebuffer.
In order for the stereo you need to duplicate those framebuffers + all the textures attached to them. Here is very tricky because you don't know if a texture will be attached to a framebuffer or used somewhere else... + duplicating all the setting up & operations for the FBs....
You could end up allocating alot of buffers + textures very fast which are not used...
If you simply duplicate the draw calls and draw in the same offscreen framebuffer well you get stereo but unusable since the same buffer will have both eyes overlapped... I also noticed the nvidia driver getting very busy and the FPS going down all the way to 1fps in SLI configurations over time...
So while in theory this might be doable all the testing so far points out that is not...
So, the only viable option is to call the whole render loop a second time (so the same fb are used and reset) and the final output to be put in the right eye final framebuffer. Something like I am doing now but for the current frame rather than the next one... However so far I wasn't able to "make the jump" to the start of the drawing loop a second time in the same frame...
Just wanted to let anyone know:)[/quote]When I'm looking at the Vireio code, it seems like they handle this case by duplicating the offscreen buffer for each eye. Then, when it comes times to blit back to the backbuffer, they blit only to the proper eye from the proper buffer.
So, yes it would suggest you need to duplicate those buffers and draw calls, but it does not suggest that you need to do anything very tricky to make that work. They definitely do not duplicate the textures, those are used as a one-off to create the offscreen buffer, and once they are drawn they are done.
In DirectX I think these offscreen buffers are created with CreateRenderTarget. See for example:
[url]https://github.com/cybereality/Perception/blob/365d81ab54b18b426202bdbc16e986592eecf3d5/DxProxy/DxProxy/D3D9ProxySurface.cpp[/url]
Might be I'm misunderstanding the problem though.[/quote]
I am actually glad you asked ^_^
Firstly, OpenGL is C. DirectX is C++. Thus there are no classes and such. You just issues a series of commands basically to do what ever you want to do.
Now, in OGL a framebuffer to be "complete" needs at least one color texture(but you can have multiple color textures attached), depth texture, stencil texture.
If you create:
- One Color Texture
- Depth Texture
- Stencil Texture
and
you create FBO 1 with those textures attached
and
you create FBO 2 with those textures attached (same ones) => Basically you are sharing the textures BETWEEN the FBOs. So if FBO1 draws a circle and FBO2 draws a square the texture will contain BOth of them.
and this is basically where I am currently. I can stereo render just fine in duplicated FBOs. The result is that both FBOs will be identical. Thus the output is there but not usable:)
So in order to actually duplicate the FBOs I need to duplicate the textures attached to the FBOs. THus left eye + right eyes render in separate textures. (and possible other setup operations as well need to be duplicated :( )
Maybe I am missing something obvious ?
helifax said:Been doing more tests...
Unfortunately most engine don't use just one set of Framebuffers. They render quite a lot in offscreen framebuffers and then just blit those buffers in the back framebuffer.
In order for the stereo you need to duplicate those framebuffers + all the textures attached to them. Here is very tricky because you don't know if a texture will be attached to a framebuffer or used somewhere else... + duplicating all the setting up & operations for the FBs....
You could end up allocating alot of buffers + textures very fast which are not used...
If you simply duplicate the draw calls and draw in the same offscreen framebuffer well you get stereo but unusable since the same buffer will have both eyes overlapped... I also noticed the nvidia driver getting very busy and the FPS going down all the way to 1fps in SLI configurations over time...
So while in theory this might be doable all the testing so far points out that is not...
So, the only viable option is to call the whole render loop a second time (so the same fb are used and reset) and the final output to be put in the right eye final framebuffer. Something like I am doing now but for the current frame rather than the next one... However so far I wasn't able to "make the jump" to the start of the drawing loop a second time in the same frame...
Just wanted to let anyone know:)
When I'm looking at the Vireio code, it seems like they handle this case by duplicating the offscreen buffer for each eye. Then, when it comes times to blit back to the backbuffer, they blit only to the proper eye from the proper buffer.
So, yes it would suggest you need to duplicate those buffers and draw calls, but it does not suggest that you need to do anything very tricky to make that work. They definitely do not duplicate the textures, those are used as a one-off to create the offscreen buffer, and once they are drawn they are done.
In DirectX I think these offscreen buffers are created with CreateRenderTarget. See for example:
Firstly, OpenGL is C. DirectX is C++. Thus there are no classes and such. You just issues a series of commands basically to do what ever you want to do.
Now, in OGL a framebuffer to be "complete" needs at least one color texture(but you can have multiple color textures attached), depth texture, stencil texture.
If you create:
- One Color Texture
- Depth Texture
- Stencil Texture
and
you create FBO 1 with those textures attached
and
you create FBO 2 with those textures attached (same ones) => Basically you are sharing the textures BETWEEN the FBOs. So if FBO1 draws a circle and FBO2 draws a square the texture will contain BOth of them.
and this is basically where I am currently. I can stereo render just fine in duplicated FBOs. The result is that both FBOs will be identical. Thus the output is there but not usable:)
So in order to actually duplicate the FBOs I need to duplicate the textures attached to the FBOs. THus left eye + right eyes render in separate textures. (and possible other setup operations as well need to be duplicated :( )
Maybe I am missing something obvious ?
1x Palit RTX 2080Ti Pro Gaming OC(watercooled and overclocked to hell)
3x 3D Vision Ready Asus VG278HE monitors (5760x1080).
Intel i9 9900K (overclocked to 5.3 and watercooled ofc).
Asus Maximus XI Hero Mobo.
16 GB Team Group T-Force Dark Pro DDR4 @ 3600.
Lots of Disks:
- Raid 0 - 256GB Sandisk Extreme SSD.
- Raid 0 - WD Black - 2TB.
- SanDisk SSD PLUS 480 GB.
- Intel 760p 256GB M.2 PCIe NVMe SSD.
Creative Sound Blaster Z.
Windows 10 x64 Pro.
etc
[quote="Pirateguybrush"]Sorry, I haven't gotten around to testing again yet - is that still going to be useful for you?[/quote]
Sure, if you managed to do more testing I could use the results;))
Pirateguybrush said:Sorry, I haven't gotten around to testing again yet - is that still going to be useful for you?
Sure, if you managed to do more testing I could use the results;))
1x Palit RTX 2080Ti Pro Gaming OC(watercooled and overclocked to hell)
3x 3D Vision Ready Asus VG278HE monitors (5760x1080).
Intel i9 9900K (overclocked to 5.3 and watercooled ofc).
Asus Maximus XI Hero Mobo.
16 GB Team Group T-Force Dark Pro DDR4 @ 3600.
Lots of Disks:
- Raid 0 - 256GB Sandisk Extreme SSD.
- Raid 0 - WD Black - 2TB.
- SanDisk SSD PLUS 480 GB.
- Intel 760p 256GB M.2 PCIe NVMe SSD.
Creative Sound Blaster Z.
Windows 10 x64 Pro.
etc
[quote="helifax"]
Now, in OGL a framebuffer to be "complete" needs at least one color texture(but you can have multiple color textures attached), depth texture, stencil texture.
If you create:
- One Color Texture
- Depth Texture
- Stencil Texture
and
you create FBO 1 with those textures attached
and
you create FBO 2 with those textures attached (same ones) => Basically you are sharing the textures BETWEEN the FBOs. So if FBO1 draws a circle and FBO2 draws a square the texture will contain BOth of them.[/quote]I don't understand this part. It doesn't make sense to me that textures are drawing. I would think that textures are attached to the frame buffer and used by a Draw call, but not affect it otherwise. I mean, it's just a photograph right?
If FBO1 draws a circle, and FBO2 draws a square, I'd expect FBO1 to have a circle with a nice photo attached, and FBO2 with a square with the same nice photo attached. Both clipped to their edges.
I'd still expect the draw calls into those offscreen render targets/buffers to require doubling, and also stereo correction on the calls. If you are getting the same image for both eyes, are you doing stereo correction there?
In the DX case, the textures are shared on the pipeline, not on buffers. They are attached by calls that specify they are active and available in the pipeline, but I don't think they are considered specific to a given buffer, just active.
In DX, it's not really C++ either, it's all fake C++. No inheritance, and no encapsulation. The only thing they use inheritance for is versioning. It's effectively procedural.
helifax said:
Now, in OGL a framebuffer to be "complete" needs at least one color texture(but you can have multiple color textures attached), depth texture, stencil texture.
If you create:
- One Color Texture
- Depth Texture
- Stencil Texture
and
you create FBO 1 with those textures attached
and
you create FBO 2 with those textures attached (same ones) => Basically you are sharing the textures BETWEEN the FBOs. So if FBO1 draws a circle and FBO2 draws a square the texture will contain BOth of them.
I don't understand this part. It doesn't make sense to me that textures are drawing. I would think that textures are attached to the frame buffer and used by a Draw call, but not affect it otherwise. I mean, it's just a photograph right?
If FBO1 draws a circle, and FBO2 draws a square, I'd expect FBO1 to have a circle with a nice photo attached, and FBO2 with a square with the same nice photo attached. Both clipped to their edges.
I'd still expect the draw calls into those offscreen render targets/buffers to require doubling, and also stereo correction on the calls. If you are getting the same image for both eyes, are you doing stereo correction there?
In the DX case, the textures are shared on the pipeline, not on buffers. They are attached by calls that specify they are active and available in the pipeline, but I don't think they are considered specific to a given buffer, just active.
In DX, it's not really C++ either, it's all fake C++. No inheritance, and no encapsulation. The only thing they use inheritance for is versioning. It's effectively procedural.
Acer H5360 (1280x720@120Hz) - ASUS VG248QE with GSync mod - 3D Vision 1&2 - Driver 372.54
GTX 970 - i5-4670K@4.2GHz - 12GB RAM - Win7x64+evilKB2670838 - 4 Disk X25 RAID
SAGER NP9870-S - GTX 980 - i7-6700K - Win10 Pro 1607 Latest 3Dmigoto Release Bo3b's School for ShaderHackers
[quote="bo3b"][quote="helifax"]
Now, in OGL a framebuffer to be "complete" needs at least one color texture(but you can have multiple color textures attached), depth texture, stencil texture.
If you create:
- One Color Texture
- Depth Texture
- Stencil Texture
and
you create FBO 1 with those textures attached
and
you create FBO 2 with those textures attached (same ones) => Basically you are sharing the textures BETWEEN the FBOs. So if FBO1 draws a circle and FBO2 draws a square the texture will contain BOth of them.[/quote]I don't understand this part. It doesn't make sense to me that textures are drawing. I would think that textures are attached to the frame buffer and used by a Draw call, but not affect it otherwise. I mean, it's just a photograph right?
If FBO1 draws a circle, and FBO2 draws a square, I'd expect FBO1 to have a circle with a nice photo attached, and FBO2 with a square with the same nice photo attached. Both clipped to their edges.
I'd still expect the draw calls into those offscreen render targets/buffers to require doubling, and also stereo correction on the calls. If you are getting the same image for both eyes, are you doing stereo correction there?
In the DX case, the textures are shared on the pipeline, not on buffers. They are attached by calls that specify they are active and available in the pipeline, but I don't think they are considered specific to a given buffer, just active.
In DX, it's not really C++ either, it's all fake C++. No inheritance, and no encapsulation. The only thing they use inheritance for is versioning. It's effectively procedural.[/quote]
That is what I expected. However, is not like that. Sharing textures between Framebuffer is more efective than swapping the FBOs. All the draw calls that are issued when and FBO is active must draw somewhere... It draws on those textures that are attached.
When you bind a FBO you can specify what is the COLOR attachement you want to draw/read to/from. So if two FBOs share the same color texture both of them will Write in the same texture (overlapping).
You can read more here about this as well: [url=http://www.opengl.org/wiki/Framebuffer_Object]http://www.opengl.org/wiki/Framebuffer_Object[/url].
Maybe I am not understanding it correctly, or something. But, all the testing shows this as well...
So, I do need to duplicate the FBOs and the textures so each FBO has a unique set of textures attached to it... which ofcourse will increase the rendering time (switching between the FBOs and so on)...
To show exactly what I mean:
- Image captured from RAGE. I am duplicating the FBOs but attaching the same textures to set of duplicated FBOs:
[url=http://www.iforce.co.nz/View.aspx?i=gcmmdx12.gfh.bmp][img]http://iforce.co.nz/i/gcmmdx12.gfh.bmp[/img][/url]
- Each eye will contain exactly the image shown above (instead of left having the left perspective and so on)
helifax said:
Now, in OGL a framebuffer to be "complete" needs at least one color texture(but you can have multiple color textures attached), depth texture, stencil texture.
If you create:
- One Color Texture
- Depth Texture
- Stencil Texture
and
you create FBO 1 with those textures attached
and
you create FBO 2 with those textures attached (same ones) => Basically you are sharing the textures BETWEEN the FBOs. So if FBO1 draws a circle and FBO2 draws a square the texture will contain BOth of them.
I don't understand this part. It doesn't make sense to me that textures are drawing. I would think that textures are attached to the frame buffer and used by a Draw call, but not affect it otherwise. I mean, it's just a photograph right?
If FBO1 draws a circle, and FBO2 draws a square, I'd expect FBO1 to have a circle with a nice photo attached, and FBO2 with a square with the same nice photo attached. Both clipped to their edges.
I'd still expect the draw calls into those offscreen render targets/buffers to require doubling, and also stereo correction on the calls. If you are getting the same image for both eyes, are you doing stereo correction there?
In the DX case, the textures are shared on the pipeline, not on buffers. They are attached by calls that specify they are active and available in the pipeline, but I don't think they are considered specific to a given buffer, just active.
In DX, it's not really C++ either, it's all fake C++. No inheritance, and no encapsulation. The only thing they use inheritance for is versioning. It's effectively procedural.
That is what I expected. However, is not like that. Sharing textures between Framebuffer is more efective than swapping the FBOs. All the draw calls that are issued when and FBO is active must draw somewhere... It draws on those textures that are attached.
When you bind a FBO you can specify what is the COLOR attachement you want to draw/read to/from. So if two FBOs share the same color texture both of them will Write in the same texture (overlapping).
You can read more here about this as well: http://www.opengl.org/wiki/Framebuffer_Object.
Maybe I am not understanding it correctly, or something. But, all the testing shows this as well...
So, I do need to duplicate the FBOs and the textures so each FBO has a unique set of textures attached to it... which ofcourse will increase the rendering time (switching between the FBOs and so on)...
To show exactly what I mean:
- Image captured from RAGE. I am duplicating the FBOs but attaching the same textures to set of duplicated FBOs:
- Each eye will contain exactly the image shown above (instead of left having the left perspective and so on)
1x Palit RTX 2080Ti Pro Gaming OC(watercooled and overclocked to hell)
3x 3D Vision Ready Asus VG278HE monitors (5760x1080).
Intel i9 9900K (overclocked to 5.3 and watercooled ofc).
Asus Maximus XI Hero Mobo.
16 GB Team Group T-Force Dark Pro DDR4 @ 3600.
Lots of Disks:
- Raid 0 - 256GB Sandisk Extreme SSD.
- Raid 0 - WD Black - 2TB.
- SanDisk SSD PLUS 480 GB.
- Intel 760p 256GB M.2 PCIe NVMe SSD.
Creative Sound Blaster Z.
Windows 10 x64 Pro.
etc
Here again, I'm not well versed on OpenGL, but maybe this is helping.
For the framebuffer objects and other buffers, I'm pretty sure you do not need to duplicate those.
The main reason is that all of that stuff is the same regardless of eye position. Take for example the two basic building blocks of vertex buffers, and texture maps. Those have to be assigned to the GPU using calls, but are assigned as data objects to be used by drawing, not actually drawn. The shaders do the actual drawing using those as input.
Vertex buffers are just a list of vertices that build the 3D model, the wireframe. This would not change based on eye position, because it's the 3D model of the world, and is the same for both eyes. Slightly different viewpoint, but sort of the same as rotating all around a 3D model.
The texture maps are painted onto the wire frame, and are also the same data for either eye. The angle they display at might be different, but the raw data is the same in each case, just like the vertices.
So, unless I'm missing something, or we're talking about different buffers, I don't think any of that data needs to be duplicated.
Acer H5360 (1280x720@120Hz) - ASUS VG248QE with GSync mod - 3D Vision 1&2 - Driver 372.54
GTX 970 - i5-4670K@4.2GHz - 12GB RAM - Win7x64+evilKB2670838 - 4 Disk X25 RAID
SAGER NP9870-S - GTX 980 - i7-6700K - Win10 Pro 1607
Latest 3Dmigoto Release
Bo3b's School for ShaderHackers
:) I know you have Broken Age. Did you had time to try out the new wrapper? From the previous page?
Thx in advance;))
1x Palit RTX 2080Ti Pro Gaming OC(watercooled and overclocked to hell)
3x 3D Vision Ready Asus VG278HE monitors (5760x1080).
Intel i9 9900K (overclocked to 5.3 and watercooled ofc).
Asus Maximus XI Hero Mobo.
16 GB Team Group T-Force Dark Pro DDR4 @ 3600.
Lots of Disks:
- Raid 0 - 256GB Sandisk Extreme SSD.
- Raid 0 - WD Black - 2TB.
- SanDisk SSD PLUS 480 GB.
- Intel 760p 256GB M.2 PCIe NVMe SSD.
Creative Sound Blaster Z.
Windows 10 x64 Pro.
etc
My website with my fixes and OpenGL to 3D Vision wrapper:
http://3dsurroundgaming.com
(If you like some of the stuff that I've done and want to donate something, you can do it with PayPal at tavyhome@gmail.com)
Hmm, I do think I need to duplicate some of them:
By default you have one framebuffer glBindFramebuffer(GL_FRAME_BUFFER, 0).
Most apps generate additional GL_FRAME_BUFFERS (1,2,etc) to draw certain elements of the final picture in them.
Then at the end they switch back to framebuffer 0 and copy the content from those buffers.
And swap the buffers.
Now If I only duplicate GL_FRAME_BUFFER_0 (for left + right eyes) I will only get stereo on what is actually glDrawXXXX in the GL_FRAME_BUFFER_0.
So if I have glDrawXXX on GL_FRAME_BUFFER_2 basically I need to duplicate these buffers as well so I can render those elements in stereo as well.
All the other types of Buffers and VAOs, VBOs don't need a duplication. Don't you agree ?
1x Palit RTX 2080Ti Pro Gaming OC(watercooled and overclocked to hell)
3x 3D Vision Ready Asus VG278HE monitors (5760x1080).
Intel i9 9900K (overclocked to 5.3 and watercooled ofc).
Asus Maximus XI Hero Mobo.
16 GB Team Group T-Force Dark Pro DDR4 @ 3600.
Lots of Disks:
- Raid 0 - 256GB Sandisk Extreme SSD.
- Raid 0 - WD Black - 2TB.
- SanDisk SSD PLUS 480 GB.
- Intel 760p 256GB M.2 PCIe NVMe SSD.
Creative Sound Blaster Z.
Windows 10 x64 Pro.
etc
My website with my fixes and OpenGL to 3D Vision wrapper:
http://3dsurroundgaming.com
(If you like some of the stuff that I've done and want to donate something, you can do it with PayPal at tavyhome@gmail.com)
Game launches, is 3d. However there appear to be missing textures, occasional broken shaders, and no mouse cursor. Getting about 1fps with SLI, or 60 without. The scene in Vella's house at the start was completely flat+depth. I don't know if that's just this particular scene though.
When I try it with the old version, it loads up your custom splash screen, and nothing else happens. Sits in task manager using about 1.5mb of ram, even after closing the splash screen. It's not selectable on the task bar. It did load once, but almost everything was black.
That is very very strange... What version of the game are you using ? from Steam? I am wondering if it got patched or something... (since I am using A steam one but cracked so not updated in case they updated the game).
Also have you tried to delete the Shaders Folder and see if the SLI performance increases?
1x Palit RTX 2080Ti Pro Gaming OC(watercooled and overclocked to hell)
3x 3D Vision Ready Asus VG278HE monitors (5760x1080).
Intel i9 9900K (overclocked to 5.3 and watercooled ofc).
Asus Maximus XI Hero Mobo.
16 GB Team Group T-Force Dark Pro DDR4 @ 3600.
Lots of Disks:
- Raid 0 - 256GB Sandisk Extreme SSD.
- Raid 0 - WD Black - 2TB.
- SanDisk SSD PLUS 480 GB.
- Intel 760p 256GB M.2 PCIe NVMe SSD.
Creative Sound Blaster Z.
Windows 10 x64 Pro.
etc
My website with my fixes and OpenGL to 3D Vision wrapper:
http://3dsurroundgaming.com
(If you like some of the stuff that I've done and want to donate something, you can do it with PayPal at tavyhome@gmail.com)
I haven't deleted the shaders folder. I can try that tomorrow.
Unfortunately most engine don't use just one set of Framebuffers. They render quite a lot in offscreen framebuffers and then just blit those buffers in the back framebuffer.
In order for the stereo you need to duplicate those framebuffers + all the textures attached to them. Here is very tricky because you don't know if a texture will be attached to a framebuffer or used somewhere else... + duplicating all the setting up & operations for the FBs....
You could end up allocating alot of buffers + textures very fast which are not used...
If you simply duplicate the draw calls and draw in the same offscreen framebuffer well you get stereo but unusable since the same buffer will have both eyes overlapped... I also noticed the nvidia driver getting very busy and the FPS going down all the way to 1fps in SLI configurations over time...
So while in theory this might be doable all the testing so far points out that is not...
So, the only viable option is to call the whole render loop a second time (so the same fb are used and reset) and the final output to be put in the right eye final framebuffer. Something like I am doing now but for the current frame rather than the next one... However so far I wasn't able to "make the jump" to the start of the drawing loop a second time in the same frame...
Just wanted to let anyone know:)
1x Palit RTX 2080Ti Pro Gaming OC(watercooled and overclocked to hell)
3x 3D Vision Ready Asus VG278HE monitors (5760x1080).
Intel i9 9900K (overclocked to 5.3 and watercooled ofc).
Asus Maximus XI Hero Mobo.
16 GB Team Group T-Force Dark Pro DDR4 @ 3600.
Lots of Disks:
- Raid 0 - 256GB Sandisk Extreme SSD.
- Raid 0 - WD Black - 2TB.
- SanDisk SSD PLUS 480 GB.
- Intel 760p 256GB M.2 PCIe NVMe SSD.
Creative Sound Blaster Z.
Windows 10 x64 Pro.
etc
My website with my fixes and OpenGL to 3D Vision wrapper:
http://3dsurroundgaming.com
(If you like some of the stuff that I've done and want to donate something, you can do it with PayPal at tavyhome@gmail.com)
So, yes it would suggest you need to duplicate those buffers and draw calls, but it does not suggest that you need to do anything very tricky to make that work. They definitely do not duplicate the textures, those are used as a one-off to create the offscreen buffer, and once they are drawn they are done.
In DirectX I think these offscreen buffers are created with CreateRenderTarget. See for example:
https://github.com/cybereality/Perception/blob/365d81ab54b18b426202bdbc16e986592eecf3d5/DxProxy/DxProxy/D3D9ProxySurface.cpp
Might be I'm misunderstanding the problem though.
Acer H5360 (1280x720@120Hz) - ASUS VG248QE with GSync mod - 3D Vision 1&2 - Driver 372.54
GTX 970 - i5-4670K@4.2GHz - 12GB RAM - Win7x64+evilKB2670838 - 4 Disk X25 RAID
SAGER NP9870-S - GTX 980 - i7-6700K - Win10 Pro 1607
Latest 3Dmigoto Release
Bo3b's School for ShaderHackers
I am actually glad you asked ^_^
Firstly, OpenGL is C. DirectX is C++. Thus there are no classes and such. You just issues a series of commands basically to do what ever you want to do.
Now, in OGL a framebuffer to be "complete" needs at least one color texture(but you can have multiple color textures attached), depth texture, stencil texture.
If you create:
- One Color Texture
- Depth Texture
- Stencil Texture
and
you create FBO 1 with those textures attached
and
you create FBO 2 with those textures attached (same ones) => Basically you are sharing the textures BETWEEN the FBOs. So if FBO1 draws a circle and FBO2 draws a square the texture will contain BOth of them.
and this is basically where I am currently. I can stereo render just fine in duplicated FBOs. The result is that both FBOs will be identical. Thus the output is there but not usable:)
So in order to actually duplicate the FBOs I need to duplicate the textures attached to the FBOs. THus left eye + right eyes render in separate textures. (and possible other setup operations as well need to be duplicated :( )
Maybe I am missing something obvious ?
1x Palit RTX 2080Ti Pro Gaming OC(watercooled and overclocked to hell)
3x 3D Vision Ready Asus VG278HE monitors (5760x1080).
Intel i9 9900K (overclocked to 5.3 and watercooled ofc).
Asus Maximus XI Hero Mobo.
16 GB Team Group T-Force Dark Pro DDR4 @ 3600.
Lots of Disks:
- Raid 0 - 256GB Sandisk Extreme SSD.
- Raid 0 - WD Black - 2TB.
- SanDisk SSD PLUS 480 GB.
- Intel 760p 256GB M.2 PCIe NVMe SSD.
Creative Sound Blaster Z.
Windows 10 x64 Pro.
etc
My website with my fixes and OpenGL to 3D Vision wrapper:
http://3dsurroundgaming.com
(If you like some of the stuff that I've done and want to donate something, you can do it with PayPal at tavyhome@gmail.com)
Sure, if you managed to do more testing I could use the results;))
1x Palit RTX 2080Ti Pro Gaming OC(watercooled and overclocked to hell)
3x 3D Vision Ready Asus VG278HE monitors (5760x1080).
Intel i9 9900K (overclocked to 5.3 and watercooled ofc).
Asus Maximus XI Hero Mobo.
16 GB Team Group T-Force Dark Pro DDR4 @ 3600.
Lots of Disks:
- Raid 0 - 256GB Sandisk Extreme SSD.
- Raid 0 - WD Black - 2TB.
- SanDisk SSD PLUS 480 GB.
- Intel 760p 256GB M.2 PCIe NVMe SSD.
Creative Sound Blaster Z.
Windows 10 x64 Pro.
etc
My website with my fixes and OpenGL to 3D Vision wrapper:
http://3dsurroundgaming.com
(If you like some of the stuff that I've done and want to donate something, you can do it with PayPal at tavyhome@gmail.com)
If FBO1 draws a circle, and FBO2 draws a square, I'd expect FBO1 to have a circle with a nice photo attached, and FBO2 with a square with the same nice photo attached. Both clipped to their edges.
I'd still expect the draw calls into those offscreen render targets/buffers to require doubling, and also stereo correction on the calls. If you are getting the same image for both eyes, are you doing stereo correction there?
In the DX case, the textures are shared on the pipeline, not on buffers. They are attached by calls that specify they are active and available in the pipeline, but I don't think they are considered specific to a given buffer, just active.
In DX, it's not really C++ either, it's all fake C++. No inheritance, and no encapsulation. The only thing they use inheritance for is versioning. It's effectively procedural.
Acer H5360 (1280x720@120Hz) - ASUS VG248QE with GSync mod - 3D Vision 1&2 - Driver 372.54
GTX 970 - i5-4670K@4.2GHz - 12GB RAM - Win7x64+evilKB2670838 - 4 Disk X25 RAID
SAGER NP9870-S - GTX 980 - i7-6700K - Win10 Pro 1607
Latest 3Dmigoto Release
Bo3b's School for ShaderHackers
That is what I expected. However, is not like that. Sharing textures between Framebuffer is more efective than swapping the FBOs. All the draw calls that are issued when and FBO is active must draw somewhere... It draws on those textures that are attached.
When you bind a FBO you can specify what is the COLOR attachement you want to draw/read to/from. So if two FBOs share the same color texture both of them will Write in the same texture (overlapping).
You can read more here about this as well: http://www.opengl.org/wiki/Framebuffer_Object.
Maybe I am not understanding it correctly, or something. But, all the testing shows this as well...
So, I do need to duplicate the FBOs and the textures so each FBO has a unique set of textures attached to it... which ofcourse will increase the rendering time (switching between the FBOs and so on)...
To show exactly what I mean:
- Image captured from RAGE. I am duplicating the FBOs but attaching the same textures to set of duplicated FBOs:
- Each eye will contain exactly the image shown above (instead of left having the left perspective and so on)
1x Palit RTX 2080Ti Pro Gaming OC(watercooled and overclocked to hell)
3x 3D Vision Ready Asus VG278HE monitors (5760x1080).
Intel i9 9900K (overclocked to 5.3 and watercooled ofc).
Asus Maximus XI Hero Mobo.
16 GB Team Group T-Force Dark Pro DDR4 @ 3600.
Lots of Disks:
- Raid 0 - 256GB Sandisk Extreme SSD.
- Raid 0 - WD Black - 2TB.
- SanDisk SSD PLUS 480 GB.
- Intel 760p 256GB M.2 PCIe NVMe SSD.
Creative Sound Blaster Z.
Windows 10 x64 Pro.
etc
My website with my fixes and OpenGL to 3D Vision wrapper:
http://3dsurroundgaming.com
(If you like some of the stuff that I've done and want to donate something, you can do it with PayPal at tavyhome@gmail.com)