[Announcement: Skybox in 2.06]

TDM 2.06 will have a special optimization for skybox surfaces that use the textures/smf/portal_sky material.

The caulk sky won't have it and will be slower to draw.

[New Monitor Settings]

I have a 32" widescreen monitor. In game settings don't let me go full screen at that width, and I cannot seem to find the correct resolution to set. My settings is Thief 2 however work fullscreen and they are 2560x1080x32. Is there a way to specifiy in darkmod.cfg the correct settings and what might those be? Thank you.

r_customwidth 2560

r_customheight 1080

[Custom frob idea]

My 5 cents.

I don't like how TDM handles frob now. Each frobable material has these two extra stages, and not only it makes loading a map slower (because of extra data parsing) but it also adds extra draw call when an entity is selected.

Instead I would propose to highlight the entity in the standard ambient shader by simple color add. (cubemap wrap, etc).

This way once changed in the GPU shader code it would apply to all materials.

It would also allow different. configurable frob visuals.

[8K VR Headset - Pimax]

Makes you kinda wish they bundled a blackjack controller, Wii-style.

[I'm working on a VR version - early alpha]

@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 about adding the VR code in the trunk svn?

[Forum processes attached images... poorly]

It might be set up to save space by resizing attachments, but it's saving on processing times by using a fast compress path.

Supposedly, but what prevents it to compare the output size with the original and discard the bigger one?

[Forum processes attached images... poorly]

EDIT: nope, that's not the case, if I full screen the image and download it, it's twice the size in MB, but it's image size is smaller, so the forum is resizing and recompressing, but probably doing it as fastest path instead of smallest path.

Prompts the question: why recompress at all if the result is worse that the original?

[I'm working on a VR version - early alpha]

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.

[fhDOOM engine improvements]

Another reference:

 

https://learnopengl.com/?_escaped_fragment_=Advanced-Lighting/Shadows/Point-Shadows#!Advanced-Lighting/Shadows/Point-Shadows

 

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)

[Forum processes attached images... poorly]

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.

Untitled.png.txt

[fhDOOM engine improvements]

Typically by splitting it into six shadow maps (or a cube map) for each room direction.

Render geometry 6 times? Or ??

[fhDOOM engine improvements]

How do you make a shadow map for a point light?

[I'm working on a VR version - early alpha]

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.

[I'm working on a VR version - early alpha]

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?

[I'm working on a VR version - early alpha]

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

[I'm working on a VR version - early alpha]

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.

[I'm working on a VR version - early alpha]

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

[I'm working on a VR version - early alpha]

 

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

[I'm working on a VR version - early alpha]

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.

[I'm working on a VR version - early alpha]

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

[I'm working on a VR version - early alpha]

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?

[I'm working on a VR version - early alpha]

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?

[The Caduceus of St. Alban: Vertical FM Contest entry: Aug 8th, 2010]

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:

 

[I'm working on a VR version - early alpha]

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?

[I'm working on a VR version - early alpha]

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.