duzenko
-
Posts
4149 -
Joined
-
Last visited
-
Days Won
50
Posts posted by duzenko
-
-
Another reference:
I am still skeptical of a shadow mapping approach. Shadow maps are faster for "static" lights. Moving lights have only recently been possible with
shadow maps and the number of them allowed for engines which feature this are typically far lower than a standard Id Tech 4 map.
Though, I have heard that tile based shadow maps have solved this. http://hd-prg.com/tileBasedShadows.html
I would expect both approaches have roughly similar speed in general, with the exception that stencil shadows are culled to light screen size projection while shadow maps are usually fixed in size.
E.g. when player is a room fully lit by a couple lights (Officer Lounge in Fence) stencil light will draw in full screen size twice, while shadow map could draw in 512x512 buffer.
But then player is in the street with many small lights stencil could draw each light in a screen region as small as dozens of pixels, while shadow map is still 512x512 (not that there's no way to add LOD's to that as well)
-
I noticed that when I upload a compressed .png the uploaded file size is usually much bigger than the original.
Is there something we could do about it?
Here's an example.
-
Typically by splitting it into six shadow maps (or a cube map) for each room direction.
Render geometry 6 times? Or ??
-
How do you make a shadow map for a point light?
-
Doesn't access flags tell driver that mapping is also one-way? (e.g. GL_MAP_WRITE_BIT | GL_MAP_INVALIDATE_BUFFER_BIT).
The problem with that is the function still needs to return a pointer to driver's internal data while the other one does not return anything.
-
1
-
-
I found a bug:
com_smp 0 vid_restart com_smp 1
Then something like Stgatilov described above happens
@Cabalistic, could you look?
Also
com_smp 1 vid_restart
results in black screen. Thread sync lockup?
-
1
-
-
@duzenko: Ok, but did you see any benefits?
For us to make the proper use of mapbufferrange I think we should do one mapbufferrange per frame rather than per each surface like now.
Re dynamic models: I think whatever method we could possibly use to upload data to GPU will still be much faster than instantiate the model and derive tangents.
Conclusion: static geometry is fast enough as it is, dynamic geometry needs GPU skinning. The existing vertex cache is not a speed bump, and only needs whatever changes necessary to support GPU skinning.
An interesting point on the mapbufferrange: it can be actually slower than buffersubdata because the latter is one way and can be nicely queued for the driver thread.
-
1
-
-
Ok, but then it's just going to cause merge conflicts with my deeper modifications
(Nothing git can't handle, though, so doesn't matter.)
Nothing to merge really, simply overwrite with your version when it's fully working.
-
@duzenko: Ok, but did you see any benefits?
Not really, but it's a part of the bigger process of updating the engine.
We should end with the BFG engine in the end, and this is one of the many steps.
-
With com_smp enabled, I do not see the menu.
If I enable it only during playing a mission, then console starts jumping up/down, then some weird text appears (font texture, I suppose), and finally everything crashes.
Actually, it crashes the whole Oracle VM, not just the TDM process
Making sure com_smp is always 0 on Linux is one way to go.
Unless someone knows enough about how OpenGL interacts with Linux OS.
I think that looks like video driver bug
-
Pat Raynor's variant is only a relatively simple change that changed the existing temp allocations to a MapBuffer approach without changing the general structure of the VertexCache. I actually ported the whole BFG VertexCache concept.
Again, on its own that probably isn't really worth the effort, but I expect it to make porting additional stuff easier.
I ported Raynor's MapBuffer approach to trunk for now until you sort out the BFG's incompatibilities.
-
Hm, and these are still based on stencil shadows? What's the performance like?
Only SteveL knows but since I think his approach is stencil texture in FBO it should be roughly the same
-
1
-
-
So, this weekend I went ahead and ported the BFG-style VertexCache in full. This means that, instead of two frame temporary buffers and lots of individual vbos, there are now two larger frame temporary buffers and a single static buffer. The static buffer is filled during level load with static interactions and static model data. Everything else is now allocated on the temporary buffers and thus only valid for a single frame.
This means that the frontend no longer needs to make GL calls, which also means that it no longer needs the shared context and does not have to sync its GL calls. On the other hand, it also means that it currently probably recreates some vertex caches a lot more often than previously, since they are only valid for a single frame.
How about the light interaction geometry?
Are vertexes duplicated or indexes only each frame?
-
1
-
-
It isn't. It happens before the main render on the main thread, while the frontend thread is idling. So basically, it's running exclusively.
Hm, unless it's accessing buffers that the frontend wrote to and are still syncing? That's the only thing I could think of...
Do the crashes go away if you disable com_smp?
Not sure when I can test that, maybe not for a few weeks.
But think about this: at the time of lightgem's CaptureRenderToBuffer where is the lightgem draw command - in the frame that the backend has just completed rendering or in the frame that the frontend has prepared for the next backend run?
-
1
-
-
Is there any clue for the exit location anywhere? I had to noclip to find it.
What is the meaning of the hatch between the tunnel and the barracks? Can it be opened from the barracks side?
Couple of visual errors:
-
Lightgem here needs some attention.
I get random but numerous driver crashes when it's enabled.
I can't get my head around how its drawing is synchronized with the main render?
-
1
-
-
Meanwhile, I've experimented a bit with glMapBufferRange. Changing the frame temp allocs in the VertexCache to that method is straight-forward enough, but it doesn't seem to have any noticable effect.
Try the wine cellar in Caduceus of St Alban. I'm playing this mission right now and the shadow calculation of the bottle stand and 2 nearby lights, plus the wobblesky texgens, is putting my Intel on its knees.
-
1
-
-
Meanwhile, I've experimented a bit with glMapBufferRange. Changing the frame temp allocs in the VertexCache to that method is straight-forward enough, but it doesn't seem to have any noticable effect.
Make sure that you're rendering a scene that is driver limited: GPU usage < 90%, r_showSmp is printing mostly dots.
-
1
-
-
I'm seeing the same thing Cabalistic sees.
With the "Enhanced Ambient" there is flickering and blown-out highlights. With the "Simple Ambient" everything looks just about identical to the ARB path.
GLSL ambient shader: ported from ARB minus fresnel
-
2
-
-
I'm seeing the same thing Cabalistic sees.
With the "Enhanced Ambient" there is flickering and blown-out highlights. With the "Simple Ambient" everything looks just about identical to the ARB path.
I brought the enhanced ambient glsl to the same color vertex method. Please test.
I will try to look later today at the difference between arb & glsl ambients.
-
1
-
-
Here's how this scene looks to me on a GT 640.
Can you attach your .cfg?
@Nbohre1more, how does it look for you?
-
1
-
-
There is another flickering issue. In the training mission, if you head out to the archery range, the floor flickers with white color.
You mean this room? Does not flicker to me on NV
Did you update both source code and shaders in assets svn?
-
1
-
-
The GLSL output is noticably darker, is that intentional? I find it a bit too dark, makes it difficult to see anything in unlit areas.
No, I have been trying to port the interaction shader from ARB assembly, but there's still room for improvement. Can you send your screenshots with the difference?
Is the ambient option set to simple or enhanced?
I took the ambient shader from Pat Raynor's project and did not edit it yet.
-
1
-
-
Well, this is definitely a shader issue. Here is what I found so far:
- the simpleInteraction in interaction.fs is fine and does not show flickering.
- If you remove the R1*R2 addition to color in advancedInteraction, the flickering disappears
- But if you output color just after the R1*R2 addition, there is no flicker in there.
- If you remove var_Color.rgb from the final color calculation, the flickering disappears.
- But if you output just var_Color.rgb, there is no flickering either.
What?! Ultimately, a simple multiplication of two flicker-free color values produces flickering. Either this is a driver bug, or I just don't get it.
Fixed the color flickering. The glsl mode is ready for testing.
I'm working on a VR version - early alpha
in The Dark Mod
Posted
Fix confirmed.