Jump to content


Photo

I'm working on a VR version - early alpha


  • Please log in to reply
262 replies to this topic

#201 cabalistic

cabalistic

    Member

  • Member
  • PipPip
  • 97 posts

Posted 05 September 2017 - 01:33 PM

Given that the Dark Mod engine is currently strongly CPU-bound, switching to shadow mapping would help offload work to the GPU. However, it's also a significant undertaking... Although it depends how easily the RBDOOM implementation could be adopted.

Ah well, I think GPU skinning is more important right now.


  • nbohr1more and Anderson like this

#202 AluminumHaste

AluminumHaste

    Darkmod Contributor

  • Development Role
  • PipPipPipPipPip
  • 5915 posts

Posted 05 September 2017 - 07:39 PM

Can't comment on RBDoom3BFG, I don't have BFG assets\game.

 

Check your Steam profile


I always assumed I'd taste like boot leather.

 

#203 nbohr1more

nbohr1more

    Darkmod PR, Wordsmith

  • Development Role
  • PipPipPipPipPip
  • 8128 posts

Posted 05 September 2017 - 07:50 PM

OMG!!! :wub:

 

My bar tab keeps growing I guess. I owe ya big time. :blush:  :)


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

http://www.indiedb.c...ds/the-dark-mod

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

#204 AluminumHaste

AluminumHaste

    Darkmod Contributor

  • Development Role
  • PipPipPipPipPip
  • 5915 posts

Posted 05 September 2017 - 07:50 PM

Enjoy, you deserve it!


I always assumed I'd taste like boot leather.

 

#205 duzenko

duzenko

    Advanced Member

  • Active Developer
  • PipPipPip
  • 814 posts

Posted 06 September 2017 - 06:02 AM

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.



#206 stgatilov

stgatilov

    Member

  • Development Role
  • PipPip
  • 467 posts

Posted 06 September 2017 - 07:48 AM

@stgatilov: I implemented the secondary context for Linux. However, it's segfaulting for me in the asm code in Sys_GetClockTicks. If I comment that out, main menu is working fine, but loading a mission fails.

 

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  :blink:

 

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.



#207 cabalistic

cabalistic

    Member

  • Member
  • PipPip
  • 97 posts

Posted 06 September 2017 - 07:59 AM

Hm, sounds more like an issue with the VM and potentially with the GL implementation inside that VM. I'm not sure that is a good testbed...

The SMP functionality itself works for me in a native Linux environment. It's other stuff that doesn't :)

 

@duzenko: Ok, but did you see any benefits?


Edited by cabalistic, 06 September 2017 - 08:02 AM.


#208 duzenko

duzenko

    Advanced Member

  • Active Developer
  • PipPipPip
  • 814 posts

Posted 06 September 2017 - 08:35 AM

 

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  :blink:

 

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



#209 duzenko

duzenko

    Advanced Member

  • Active Developer
  • PipPipPip
  • 814 posts

Posted 06 September 2017 - 08:38 AM

@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.



#210 cabalistic

cabalistic

    Member

  • Member
  • PipPip
  • 97 posts

Posted 06 September 2017 - 08:41 AM

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.

Ok, but then it's just going to cause merge conflicts with my deeper modifications :D

(Nothing git can't handle, though, so doesn't matter.)



#211 duzenko

duzenko

    Advanced Member

  • Active Developer
  • PipPipPip
  • 814 posts

Posted 06 September 2017 - 08:46 AM

Ok, but then it's just going to cause merge conflicts with my deeper modifications :D

(Nothing git can't handle, though, so doesn't matter.)

Nothing to merge really, simply overwrite with your version when it's fully working.



#212 duzenko

duzenko

    Advanced Member

  • Active Developer
  • PipPipPip
  • 814 posts

Posted 07 September 2017 - 03:24 AM

@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.


  • Anderson likes this

#213 duzenko

duzenko

    Advanced Member

  • Active Developer
  • PipPipPip
  • 814 posts

Posted 07 September 2017 - 05:06 AM

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?


  • Anderson likes this

#214 stgatilov

stgatilov

    Member

  • Development Role
  • PipPip
  • 467 posts

Posted 07 September 2017 - 10:27 AM

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.

I thought that's the main point of BFG-style VertexCache.

 

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.

That's a good question. I'm not so sure that CPU processing time really matters.

You can probably disable DeriveTangents/NormalizeTangents after 500-th frame, and see if FPS improves.

Then try disabling all VBO updates and look at it.

This way we can finally see what is the bottleneck of these two...

 

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.

Doesn't access flags tell driver that mapping is also one-way? (e.g. GL_MAP_WRITE_BIT | GL_MAP_INVALIDATE_BUFFER_BIT).


  • Anderson likes this

#215 duzenko

duzenko

    Advanced Member

  • Active Developer
  • PipPipPip
  • 814 posts

Posted 07 September 2017 - 11:07 AM

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.


  • Anderson likes this

#216 cabalistic

cabalistic

    Member

  • Member
  • PipPip
  • 97 posts

Posted 07 September 2017 - 01:13 PM

Then again, the glMapBufferRange is going to be significantly better once we begin to multithread the frontend further. That's where the current approach would need additional GL contexts and cost additional synchronisation overhead. In contrast, the mapped buffer approach can do that almost free of overhead.

 

I'll look into the vid_restart behaviour. It's probably just not implemented.


  • Anderson likes this

#217 HMart

HMart

    Advanced Member

  • Member
  • PipPipPip
  • 557 posts

Posted 08 September 2017 - 10:01 AM

Given that the Dark Mod engine is currently strongly CPU-bound, switching to shadow mapping would help offload work to the GPU. However, it's also a significant undertaking... Although it depends how easily the RBDOOM implementation could be adopted.

Ah well, I think GPU skinning is more important right now.

 

Yes GPU skinning is more important i agree, but personally after that is done, it wouldn't be hard, i assume, to see how fhDOOM engine does shadow maps, fhDOOM is based on the original idtech 4 after all, just like TDM, so perhaps is a matter of direct copy pasting? 


  • Anderson likes this

#218 nbohr1more

nbohr1more

    Darkmod PR, Wordsmith

  • Development Role
  • PipPipPipPipPip
  • 8128 posts

Posted 08 September 2017 - 10:15 AM

fhDoom's shadow map implementation is slower and buggier than our old blurred stencil shadow approach.


  • Anderson likes this
Please visit TDM's IndieDB site and help promote the mod:

http://www.indiedb.c...ds/the-dark-mod

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

#219 HMart

HMart

    Advanced Member

  • Member
  • PipPipPip
  • 557 posts

Posted 08 September 2017 - 11:51 AM

fhDoom's shadow map implementation is slower and buggier than our old blurred stencil shadow approach.

 

I do agree that fhDOOM shadow mapping is still a work in progress and has space for improvement, but i think is unfair to dismiss it because of that, imo is a nice prof of concept plus is open and anyone with sufficient knowledge can improve on it, that is what GPL is all about.

 

Btw even if blurred stencil shadows are faster and on this case better looking than the fhDOOM shadow maps, like i already said they don't solve the inability of stencil shadows from casting shadows from alpha mapped textures, that to me, is the single greatest reason i don't like stencil shadows.

Games are filled with alpha mapped surfaces, we lose many of the fantastic visual atmospheres that those materials could provide, if they could cast shadows, existent idtech 4 ability to manually place projecting light's is a nice compromise but is not a replacement for real shadow casting, if i wanted to make a forest scene with stencil shadows, my only option is for the trees/grass to not cast shadows at all, that not only looks totally fake but makes geometry seam like is floating in the air, including a projected light, casting a fake shadow, in all trees would be a very time consuming matter, very tweeki prone, not very realistic and perhaps even kill the performance, this is imo also the reason all modern engines don't use stencil shadows anymore. fhDOOM has cascaded shadow maps for this reason, still with bugs i know but i'm sure nothing impossible to solve. 


  • Anderson likes this

#220 cabalistic

cabalistic

    Member

  • Member
  • PipPip
  • 97 posts

Posted 09 September 2017 - 04:28 PM

@duzenko: Looked at vid_restart, but I'm a bit baffled. For me it works fine in the main menu, but freezes ingame, no matter if com_smp is enabled or not. There is a definite problem with the frontend thread, because the thread is not shut down properly, but the vid_restart function does delete and recreate both GL contexts. I added calls to shutdown and then restart the frontend thread in vid_restart, but it still freezes. Debugger says it freezes in a glGenerateMipmap call during recreation of images.

 

At this point, I'm not sure if there isn't another issue with the video restart.


  • Anderson likes this

#221 cabalistic

cabalistic

    Member

  • Member
  • PipPip
  • 97 posts

Posted 10 September 2017 - 05:01 AM

Actually, never mind, I was just too impatient. I pushed my changes to stop and recreate the frontend thread, it's working for me now. Try it out.


  • duzenko and Anderson like this

#222 duzenko

duzenko

    Advanced Member

  • Active Developer
  • PipPipPip
  • 814 posts

Posted 11 September 2017 - 04:57 AM

Actually, never mind, I was just too impatient. I pushed my changes to stop and recreate the frontend thread, it's working for me now. Try it out.

Fix confirmed.


  • Anderson likes this

#223 grodenglaive

grodenglaive

    Member

  • Member
  • PipPip
  • 53 posts

Posted 11 September 2017 - 05:44 AM

I played through the Smiling Cutpurse on the vive yesterday. Looks great and runs so much better than the vorpx hack. A few shadows out of sync between eyes, but 99% of it looked perfect. You definitely need to lock-out the vertical mouse. I think that would be most important to make it comfortable to play while it's still seated mouse/keyboard.  


  • Anderson likes this

#224 cabalistic

cabalistic

    Member

  • Member
  • PipPip
  • 97 posts

Posted 11 September 2017 - 08:21 AM

@grodenglaive: Thanks. Yeah, mouse movement, GUI elements and the shadow issue are my priority when I continue working on the VR version. However, that probably won't happen before the release of v2.06 anymore. There are just too many changes to the engine to continue working on the 2.05 version.

How was performance?


  • Anderson likes this

#225 grodenglaive

grodenglaive

    Member

  • Member
  • PipPip
  • 53 posts

Posted 12 September 2017 - 04:37 AM

The performance was good, it ran perfectly smoothly with 4x antialiasing and 8x anisotropy (1080Ti, i7-7700k). I also tried 8x AA, but it started to jitter. 


  • Anderson likes this




0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users