Jump to content
The Dark Mod Forums
Sign in to follow this  
cabalistic

I'm working on a VR version - early alpha

Recommended Posts

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.

  • Like 2

Share this post


Link to post
Share on other sites

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.

 

Share this post


Link to post
Share on other sites
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.


Amnesty for Bikerdude!

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

 

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


Amnesty for Bikerdude!

Share this post


Link to post
Share on other sites

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


Amnesty for Bikerdude!

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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.


Amnesty for Bikerdude!

Share this post


Link to post
Share on other sites

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

  • Like 1

Amnesty for Bikerdude!

Share this post


Link to post
Share on other sites

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?

  • Like 1

Amnesty for Bikerdude!

Share this post


Link to post
Share on other sites

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

  • Like 1

Share this post


Link to post
Share on other sites

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.

  • Like 1

Amnesty for Bikerdude!

Share this post


Link to post
Share on other sites

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.

  • Like 1

Share this post


Link to post
Share on other sites

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?

  • Like 1

Share this post


Link to post
Share on other sites

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.

  • Like 1

Share this post


Link to post
Share on other sites

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

  • Like 1

Share this post


Link to post
Share on other sites

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.

  • Like 1

Amnesty for Bikerdude!

Share this post


Link to post
Share on other sites

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.

  • Like 1

Share this post


Link to post
Share on other sites

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

  • Like 1

Share this post


Link to post
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.

Sign in to follow this  

×
×
  • Create New...