Jump to content
The Dark Mod Forums

I'm working on a VR version - early alpha


cabalistic
 Share

Recommended Posts

Here's how this scene looks to me on a GT 640.

Can you attach your .cfg?

@Nbohre1more, how does it look for you?

 

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.

  • Like 1

Please visit TDM's IndieDB site and help promote the mod:

 

http://www.indiedb.com/mods/the-dark-mod

 

(Yeah, shameless promotion... but traffic is traffic folks...)

Link to comment
Share on other sites

 

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.

  • Like 1
Link to comment
Share on other sites

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. The problem, though, is that the engine also does a lot of "static" vertexcache allocations which are regularly freed again. The BFG engine doesn't even support freeing static vertexcache allocations, allowing it to do all static allocations on a single big vbo, which I'm sure would speed up the engine quite a bit. Unfortunately, the changes to support that are quite significant, and I don't think they are straight-forward to port. But I'll probably try, anyway.

  • Like 2
Link to comment
Share on other sites

 

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

  • Like 2
Link to comment
Share on other sites

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.

  • Like 1
Link to comment
Share on other sites

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.

  • Like 1
Link to comment
Share on other sites

This is my go-to stress test scene from Rightful Property:

 

post-3763-0-40647300-1497586062.jpg

 

 

...but it hits both the CPU and GPU, thus the threading patch is pretty beneficial here.

 

I'm struggling to think of a purely GPU bound scene since shadows are the biggest impact and they provoke skinning operations

on the CPU. Maybe the Cabin with all the fog particles in the 2nd part of Down by the Riverside?

  • Like 1

Please visit TDM's IndieDB site and help promote the mod:

 

http://www.indiedb.com/mods/the-dark-mod

 

(Yeah, shameless promotion... but traffic is traffic folks...)

Link to comment
Share on other sites

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?

Edited by cabalistic
  • Like 1
Link to comment
Share on other sites

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?

  • Like 1
Link to comment
Share on other sites

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?

In the one the backend was just using before, but already reset. So what I said before is actually very unlikely. I'm out of ideas for the moment. Need to know if this is related to SMP at all or not.

  • Like 1
Link to comment
Share on other sites

JUST want to say OMG! It is awesome!

 

I can't see the light gem or my equipment but not that much of an issue.

 

Have a bit of flickering with head movements and shadows are in one side of the lens if that helps.

 

Overall it's so awesome to see TDM in VR that I am besides myself with happiness and joy!!

 

THANKS!

Link to comment
Share on other sites

Cabalistic, we are seeing a few new bugs with Collision:

 

http://bugs.thedarkmod.com/view.php?id=4613

 

Do your changes allow Collision code to update "trace model cache" (Clip.cpp) in parallel?

 

Maybe we need to "atomic_thread_fence" in there?

  • Like 1

Please visit TDM's IndieDB site and help promote the mod:

 

http://www.indiedb.com/mods/the-dark-mod

 

(Yeah, shameless promotion... but traffic is traffic folks...)

Link to comment
Share on other sites

Update in parallel - no. Update in one thread, read in another - maybe? I don't think it's likely, since I'd expect this should be limited to gametics and frontend drawing, but I'd have to check to be sure.

Though I see that you reproduced the bug with threading disabled...

  • Like 2
Link to comment
Share on other sites

Fantastic!

 

I'm not seeing map_buffer_range in use here? Are the temp buffers using a hold and modify pattern? If not, they may still require buffer swapping.

(Not that I'm good enough to evaluate at this level..)

  • Like 1

Please visit TDM's IndieDB site and help promote the mod:

 

http://www.indiedb.com/mods/the-dark-mod

 

(Yeah, shameless promotion... but traffic is traffic folks...)

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

 Share


  • Recent Status Updates

    • Nort

      I just gave myself vertigo. A pleasant kind of vertigo, like the world has been lifted off my shoulders. I'll explain:
      Yesterday I saw to my dismay, that I had made my entire map two - two - units too short on every level - that every set01 piece was sticking 2 units into the ceiling. That's basically 402 brushes that needs to be realigned (minus the ground floor brushes).
      I knew enough about selections to do all of that in a very tense five minutes, and it compiled without leaks. (Thank you so much, Dark Radiant devs, for making an editor with such care for precision that you can align hundreds of brushes perfectly at once (which is not something I can say for Valve's Hammer editor, which has some serious issues on that front, which actually made me just quit it in disgust).) However, the result is that the entire level has now been stretched a barely noticable 2 units, and it will take some getting used to psychologically.
      · 0 replies
    • Nort

      My workflow is basically running from a chain of disasters, eventually trying to seek shelter in former disasters. It's not ideal - it's just my life.
      When I abandoned my first map, it was out of a typical mental breakdown, and so I returned to find a skybox void where the kitchen door should have been (due to a misplaced visportal) and two overlapping brushes Z-fighting on the kitchen floor.
      I've now cleaned up the last bit of mess, by cleanly separating every floor into its own layer. Now I can finally work on each floor in peace.
      ...not that I really needed to. Once you get skilled enough, the orthographic messes, well, I'll let this video speak for itself:
       
      · 1 reply
    • Nort

      Beams, beams, beams...
      Support beams, and cross beams, and then beams to fixate the support beams to the cross beams. The more beams you have in a map, the better. There's walls, floors and ceilings, but the rest of the map is pretty much just beams. Beams makes a thief happy.
      · 0 replies
    • jaxa

      Embracer Group is Buying Square Enix Montréal, Eidos, and Crystal Dynamics for “Only” 300 Million USD: https://wccftech.com/embracer-group-square-enix-montreal-eidos-crystal-dynamics/
      · 1 reply
    • duzenko

      Do we want fur in TDM? Like https://duzenko.github.io/webgl/
      · 6 replies
×
×
  • Create New...