So, what are you working on right now?

[Amadeus]

Yeah, you should select those cutlerly models and food models and turn change their classnmame into func_statics so they don't fly around when the ai is alerted. EDIT: Better yet, you can give those forks and knives, etc., "noclipmodel" "1" that way players don't clip on them if they climb onto the table

Edited November 15, 2023 by Amadeus

[MirceaKitsune]

5 hours ago, Amadeus said:

Yeah, you should select those cutlerly models and food models and turn change their classnmame into func_statics so they don't fly around when the ai is alerted. EDIT: Better yet, you can give those forks and knives, etc., "noclipmodel" "1" that way players don't clip on them if they climb onto the table

You can't frob and pick them up either then right? I'd rather leave them as is since I prefer as many moveables as possible to make the world feel interactive, I'd actually like if it more FM's allowed moving any small stuff around. Though I can fully confirm everything starts flying across if you alert AI in the area... then again seeing them climb on tables as food flies all over the place only makes for more fun even if unintended

[Amadeus]

Fair enough. I will say that as a player, I do get annoyed when I climb on something and then clip onto a small thing (like a fork). But that is just me

[MirceaKitsune]

1 hour ago, Amadeus said:

Fair enough. I will say that as a player, I do get annoyed when I climb on something and then clip onto a small thing (like a fork). But that is just me

Yes I hope that can be improved in the physics engine in time, though if it hasn't until now I presume more can't be done. The biggest issue is you can still get stuck very easily and have to reload a save since the player can no longer move after you touch certain corners or slopes.

[AluminumHaste]

29 minutes ago, MirceaKitsune said:

Yes I hope that can be improved in the physics engine in time, though if it hasn't until now I presume more can't be done. The biggest issue is you can still get stuck very easily and have to reload a save since the player can no longer move after you touch certain corners or slopes.

Open console, type noclip, fly to empty area, type noclip again. Losing progress isn't necessary with access to dev commands

[MirceaKitsune]

1 hour ago, AluminumHaste said:

Open console, type noclip, fly to empty area, type noclip again. Losing progress isn't necessary with access to dev commands

Usually I reload the save since I quick-save often: If I use cheats in a run not destined for it I feel like I broke my run by cheating. Then again I often noclip to go somewhere then reload, technically I didn't use the command during the continuation of my run but did to gain new knowledge, so it depends how you look at it

[Zerg Rush]

I use noclip only when I get stuck, what ocurres sometimes in some missions. Godmode in missions with much scaling and manteling (I¡m not so good in this), but this don't give an big advantage in a mission, only avoid to hurt me innecesary falling from a roof.

Notarget, to have fun in old, many times played missions, trolling guards, spawning big spiders or zombies. often with hilarious results.

[Goldwell]

Mmmm smells good! Who wants some new years stew?

 

 

[stgatilov]

I'm trying to support many mirrors/remotes/whatever potentially seeing each other.
(This won't get into 2.12 of course)

There are some issues, but in general it seems to work fine.
Of course the performance on such scenes is abysmal.

My understanding is that such things should be supported despite bad performance, simply because sometimes mappers get these situations unintentionally. For instance, you have two adjacent rooms with mirrors, and when player opens a door between them you might suddenly get two mirrors in the view. Right now renderer will break one of the mirrors. Processing both mirrors properly with lower FPS seems a better approach.
 

[joebarnin]

Brilliant!

[jaxa]

1 hour ago, stgatilov said:

There are some issues, but in general it seems to work fine.
Of course the performance on such scenes is abysmal.

My understanding is that such things should be supported despite bad performance, simply because sometimes mappers get these situations unintentionally. For instance, you have two adjacent rooms with mirrors, and when player opens a door between them you might suddenly get two mirrors in the view. Right now renderer will break one of the mirrors. Processing both mirrors properly with lower FPS seems a better approach.

Lock it to 60 FPS and you're good to go!

The fully path traced TDM of 2035 will be the real iGPU killer.

[datiswous]

On 1/8/2024 at 4:16 PM, stgatilov said:

(This won't get into 2.12 of course)

Why not? Seems this is not a feature but a bugfix.

[peter_spy]

On 1/8/2024 at 4:16 PM, stgatilov said:

There are some issues, but in general it seems to work fine.
Of course the performance on such scenes is abysmal.

Since you're working on this, have you tried restoring the original functionality, i.e. ability to set up a resolution for these? That might help with performance.

Also, when I was working with mirrors, I noticed that they disable normalmaps in the material. See how a cubemap version has those damaged surface details on the mirror surface, while real-time mirror bypasses all that.

Last but not least, have you tried making mirrors work on convex or concave surfaces, not just straight flat polygons? That would open up possibilities for very nice material effects (if used with moderation ).

Edited January 22 by peter_spy
Concave surfaces is probably bad idea...

[Goldwell]

6 minutes ago, peter_spy said:

Since you're working on this, have you tried restoring the original functionality, i.e. ability to set up a resolution for these? That might help with performance.

Also, when I was working with mirrors, I noticed that they disable normalmaps in the material. See how a cubemap version has those damaged surface details on the mirror surface, while real-time mirror bypasses all that.

Last but not least, have you tried making mirrors work on convex or concave surfaces, not just straight flat polygons? That would open up possibilities for very nice material effects (if used with moderation ).

 

That looks so bloody awesome! If we could have a mirror that looks that good, that would be insane.

[stgatilov]

6 hours ago, peter_spy said:

Since you're working on this, have you tried restoring the original functionality, i.e. ability to set up a resolution for these? That might help with performance.

Yes, I considered this idea.
But it won't help much, I believe.

Quote

Last but not least, have you tried making mirrors work on convex or concave surfaces, not just straight flat polygons? That would open up possibilities for very nice material effects (if used with moderation ).

If several mirrors are allowed, you can split your surface into individual planar polygons and hope for the best. But if you have 10+ polygons, then I suppose the best won't happen

Quote

Also, when I was working with mirrors, I noticed that they disable normalmaps in the material. See how a cubemap version has those damaged surface details on the mirror surface, while real-time mirror bypasses all that.

Internally, the material has "mirrorRenderMap" keyword which triggers rendering of subview. This subview is than copied into a texture. In the main view, the surfaces with mirror material should be rendered as any other surfaces, it can just use this dynamically generated surface.

I'm not sure what exactly you want. If you want the mirrored view to be distorted by normal map, then yes: this is definitely not supported. The reflected texture is generated as if reflected by a perfect plane. Maybe we can add some kind of warp shader that deforms the image mathematically according to the normalmap, but this would be a new feature.

 

[peter_spy]

Thanks for such detailed info!

12 minutes ago, stgatilov said:

I'm not sure what exactly you want. If you want the mirrored view to be distorted by normal map, then yes: this is definitely not supported. The reflected texture is generated as if reflected by a perfect plane. Maybe we can add some kind of warp shader that deforms the image mathematically according to the normalmap, but this would be a new feature.

I'm not sure if adding that warp shader is worth the hassle then, the current state seems like a feature, not a bug Personally I'm pretty happy with what I can do with a cubemap, and IMO that should be the way to go in most cases.

[stgatilov]

4 minutes ago, peter_spy said:

Thanks for such detailed info!

I'm not sure if adding that warp shader is worth the hassle then, the current state seems like a feature, not a bug Personally I'm pretty happy with what I can do with a cubemap, and IMO that should be the way to go in most cases.

A colleague of mine believes the true mirrored rendering is a deprecated feature today.
Given all the problems (try to put a model which is both partly in front of and partly behind the mirror) and the fact that reflection probes are unversal, perhaps he is right.

[peter_spy]

TBH, games from last two decades conditioned me to accept static mirrors and vampire player characters so much, that I don't even notice that anymore while playing

[MirceaKitsune]

12 minutes ago, stgatilov said:

A colleague of mine believes the true mirrored rendering is a deprecated feature today.
Given all the problems (try to put a model which is both partly in front of and partly behind the mirror) and the fact that reflection probes are unversal, perhaps he is right.

I agree the future is reflection probes: The old mirror system used to work back in the day because due to resource limitations, you'd have extremely low geometry in the world, thus in some areas you could have one giant floor or wall as a mirror. Today the target is PBR, as we'll want every surface with a specular channel to have a bit of reflection shining through. Of course one-way sharp mirrors should continue working as well, but hopefully under a new system that supports universal reflections the right way... definitely not a 2.12 thing but maybe something to dream of for 2.13.

[Geep]

  I have just released a new utility, "refont", as an open-source, partial-successor of the traditional "q3font", used to tweak the spacing and placement of TDM's bitmap font characters. For the whole story, see the new wiki page Refont.

[Geep]

This last month, I've been exploring TDM's font situation, and improving the documentation as I go. In the wiki, "Font Conversion & Repair" was rewritten, with parts broken out and expanded as:

• Font Files
• Font Metrics & DAT File Format
• Font Bitmaps in DDS Files
• ExportFontToDoom3
• Q3Font
• Refont

As announced earlier, that last item is a new C++ console utility for revising font metrics in DAT files; essentially another alternative to Q3Font and Font Patcher. It now has additional functionality that provides font-coverage analysis. A summary of current results across all TDM fonts is reported in the forum thread "Analysis of 2.12 TDM Fonts". Also, refont allows its human-readable outputs to be decorated with an annotation for each character (out of 256 codepoints). Associated with that, I've just created and released 4 annotation files:

• 1 Cyrillic version for TDM's russian map
• 3 variants for TDM's custom english/european char map.

One of the variants was derived from another new mapping file that is now available from existing wiki article "I18N - Charset". Within that file is a list, in a standard format, of the 256 TDM bitmap codepoints mapped to the corresponding Unicode U+NNNN value and name. This may be useful in defining TDM's mapping to TTF font editing programs.

For all these wiki pages mentioned, I imagine there will be additional cross-links and tweaks. But pretty much done.