k8vavoom: no good thing ever dies!

[ketmar]

@ENEMY!!! yeah. the hardest part, actually, is to determine if any mobj is inside an polyobject. if polyobject is huge (big rectangle, for example), and mobj is small, mobj may be inside an polyobject, but could never touch any of the edges. Doom coldet knows current subsector because it performs BSP lookups, but polyobjects are not in map BSP anymore. so it may require quite expensive caluclations. it's cheap for 5-10 polyobjects, but i'm pretty sure that people will start abuse the feature, building complex structures from polyobject "parts", so i'd better think about speed in advance.

 

another problem is rendering polyobject floors and ceilings: as pobj is not guaranteed to be convex, i need to re-split it to convex parts. beside this, i need to recalculate offsets and rotation angles for flats on each polyobj moving/rotation (which is not that hard, but still require some math i haet to do ;-).

 

the basic code is already working -- 3d polyobject can freely move above/below mobjs, and hitscan attacks know about pobj flats. but i'm still not sure how to solve "point inside pobj" problem fast. i can dynamically build local BSP tress for polyobjects (and this is prolly the only good way), but i feel that it could be done easier. that's why i'm still in "researching" phase.

 

i am sure that people will find alot of uses for moving 3d floors (and i think i can't even imagine what those uses will be ;-). that's why i really want to implement 'em. theoretically, it will be possible to place 3d polyobjects one above another to build things like moving railway trucks you can walk inside and so on. i'm sure people will try, that's why the engine should be able to process alot of polyobjects without heavy slowdown. ;-)

Edited March 18, 2021 by ketmar

[ketmar]

it seems that i managed to implement PoC of 3d polyobjects. at least they block vertical movement, and have thier floors and ceilings rendered. ;-) i still need to properly offset and rotate flats on pobj movement, tho.

 

if anybody's interested, "point-in-pobj" problem was solved in a hacky way. nodes builder already splitting all pobjs to convex subsectors, and it is easy to check if point/box is inside a convex subsector. it should be quite fast (i don't expect alot of mobjs standing on 3d polyobject, and check is optimised via blockmap).

 

3d polyobjects cannot carry/rotate things yet, i'll implement it later.

 

of course, this is quick-and-dirty code, and i expect to find alot of bugs there, but it seems that we can have 3d pobjs without signigicant slowdowns.

 

also, we'll prolly need some new ACSFs to set pobj flags, like "should carry objects", "should rotate objects", and so on, and to change 3d pobj z position.

 

let's hope i won't hit some unexpected corner case. ;-)

Edited March 18, 2021 by ketmar

[ketmar]

it may not look cool and exciting, but this is 3d polyobject, and i am standing on top of it. ;-)

 

Spoiler

 

[damned]

Is it possible to do it like really 3d, like 3d floors (space under and below) or would it be possible to use it only as a step from the floor or ceiling?

[ketmar]

15 minutes ago, damned said:

Is it possible to do it like really 3d, like 3d floors (space under and below)

this. i simply not implemented API to move 'em up and down yet, so they can spawn only at a floor, or at a ceiling. but they're like 3d floors, yeah, and in the engine they already have height and z position.

[Gez]

That's the second Doom port with full 3D polyobjects -- and the first that actually remained a Doom port, what with the other being Sonic Robo Blast 2.

[ketmar]

@Gez: yeah, i just thought that if they could do it, then i can do it too. as i just rewrote the whole pobj management code anyway, there couldn't be a better time for it.

[ketmar]

some funny video: download.

[ketmar]

and more. sorry for spaming. ;-)

[ketmar]

so, 3d polyobjects (let's call them "platforms" for now; i need a better word!) can carry things, rotate things, monsters on 3d platforms can see and hear the player, and so on. it means that all basic parts are in place and working. i hope that you'll be able to try platforms in the next build (demo map and documentation will be included).

 

interesting fact: each mobj in the engine tracks its current sector; and mobjs standing on a platform has platform sector as their current. which means that in theory, you can have platforms with damaging floors, for example. or you can mark platform as a secret. or change friction. for the engine, any platform is "just another map sector", nobody cares if it can move. this way i didn't even had to patch physics code, it "magically works" (the reality is slightly more complicated, but for most purposes physics "just works").

 

ah. of course, there are no restrictions on platform placement: platform over platform over platform is a valid configuration.

 

platforms cannot be translucent yet (rendering will glitch badly), and cannot be sloped. those restrictions may be removed in the future.

 

p.s.: i am slowly turning some of my promises into reality. if you've following this thread from the start, you may remember that i promised shadowmap-based lighting several years ago. it is finally here. i also promised moving sectors. well, technically they are here too (but i still consider this promise only "half-kept" ;-). sooner or later i will implement everything i promised in this thread; even wildest things i said are not just pipe dreams. join the Dark Side! ;-)

Edited March 21, 2021 by ketmar

[ketmar]

...and rotation video (vertigo warning! ;-)

[SyntherAugustus]

3d polyobjects sounds exciting

 

[Remilia Scarlet]

No 3d polyobjects in this one (it need to remain 100% compatible with GZDoom), but god I love the lighting in k8vavoom.

[ENEMY!!!]

I mentioned in The Unending thread that k8vavoom is the first source port that I've encountered that may tempt me into basing some of my future Doom modding primarily around it rather than GZDoom, thanks to a mix of @ketmar's development work and @Remilia Scarlet's demonstrations of the power of the lighting effects and shadows.  Adding 3D polyobjects/platforms will make this even more likely, especially with the level of functionality in the videos.  The main downsides of k8vavoom for me are the lack of ZScript and portals, but I can understand the reasons for them being impractical to implement (I read them when traversing the earlier discussions in this thread).  I don't see k8vavoom replacing GZDoom as my source port of choice, I can rather see myself having two favourite source ports instead of one, which is a very good thing.

Edited March 22, 2021 by ENEMY!!!

[Remilia Scarlet]

43 minutes ago, ENEMY!!! said:

the lack of ZScript and portals

Funny thing, I've never once used a portal.  There's other ways to achieve most of the same effects with just 3d floors or silent teleporters, though.  Also, portals always caused me performance issues (frame timing and input lag) the moment there was more than 2 or so visible on screen, so I never touched them.

 

ZScript is something I didn't use much to begin with.  Most of the scripting I do is honestly easier to do in ACS since it's intimately tied with the maps, not with entities.  Someday I'll take the plunge into VavoomC, though.

Edited March 22, 2021 by Remilia Scarlet

[ENEMY!!!]

I was surprised to read you'd never used portals, but I think I confused a couple of your maps with Amuscaria/Eriance's Hell-Forged ones.  I loaded up Shadows of the Nightmare Realm and Umbra of Fate and, sure enough, not a portal to be seen! 

 

I have a desktop PC that is meant to run DOOM 2016 at full speed so I've probably not felt the full extent of the performance issues with portals, but I've often noticed that portals (especially stacked sector portals) often don't play along nicely with dynamic lighting, both re. glitches and performance hits.

Edited March 22, 2021 by ENEMY!!!

[ketmar]

4 hours ago, ENEMY!!! said:

the lack of ZScript

VavoomC is more powerful. (no, really. you can create dynamic arrays and dictionaries of arbitrary user types!) not that you may need it, tho -- as i said many times, it is better to extend DECORATE instead. even gore and weapons mods bundled with k8vavoom done with DECORATE.

 

4 hours ago, ENEMY!!! said:

I don't see k8vavoom replacing GZDoom as my source port of choice, I can rather see myself having two favourite source ports instead of one, which is a very good thing.

that is the plan! i'm not going for "dethrone" any sourceport. i may making jokes like "eat that, GZDoom!" from time to time, but don't take it seriously. i started to work on Vavoom because i love it, not because i wanted to fight with GZDoom (or some other sourceport). and i am happy that people like my work. i may be little jealous when people writing things like "for GZDoom", meaning that the map needs advanced features/lighting/decorate, tho, because k8vavoom can do it too. i.e. i want people to know more about k8vavoom, not to forget about GZDoom. ;-)

 

tl;dr: you're welcome! i understand how inconvenient it may be to keep several sourceports to play different maps, and i am really happy that you found k8vavoom worth the trouble.

 

2 hours ago, ENEMY!!! said:

I've often noticed that portals (especially stacked sector portals) often don't play along nicely with dynamic lighting, both re. glitches and performance hits.

yep. it is mostly inevitable, because any kind of portals is a gross hack. k8vavoom has support for stacked sectors (yet it is somewhat broken now), but no portals (including mirrors) can have advanced features enabled. of course, it is possible to implement portals so they will allow everything, but it will be even slower (and prolly even more glitchy ;-).

 

as you may read ealier in this topic, i don't really think that portals are necessary. as Remilia wrote above, 3d floors and silent teleports usually can do the trick. even moving polyobjects already problematic for some code (expect physics being tuned during at least several next releases), and GZDoom still have some bugs with portals years after they were introduced. and it is not because GZDoom devs cannot code. ;-)

[3t0]

Could not post some time because I had too much $$$work$$$, but I have found a little slot to slack here :) now.

 

On 3/11/2021 at 11:37 AM, ketmar said:

midtex hack will allow mosters to keep walking around, and won't block sound propagation (zero-height sector blocks propagation unconditionally). 

Okay, this sounds seriously cool, now is there some ACS or LineAction that allows one to flip/assign/unassign midtexes? There has to be :D !

 

On 3/11/2021 at 12:43 PM, Gez said:

That said, if you really want to get the benefits of Immutable Geometry on your maps, there actually is a way. Keep your Doom geometry very simple -- no little border detailing, wall indents, etc. Basically keep it in a graybox stage where it handles collision and that's all. The use models to provide the detailing. Your floor models are just 0.01 unit above the "real" geometry (to avoid Z-fighting) and show a more detailed floor. Your wall models are just 0.01 unit away from the walls and they provide all the little details you may want. You would stilll need to double-up your walls (an outer one-sided layer for occlusion purposes, and an inner two-sided untextured layer for collision purpose, with your wall model sandwiched between both) but given how detail-heavy maps can feature dozens of layers per wall, you'd still save up. This massively simplifies the "dynamic" geometry while allowing a level of detail that'd be very hard to do in traditional Doom editing (go on, sculpt some organic-looking tentacles creeping along a wall, have fun playing with the hundreds of minute sloped 3D floors you'll need for that).

You have no idea @Gez - that is exactly what I tried recently (some months ago). I wanted to emulate organic/rocky wall but it is some time since I messed with 3D modeler. ~20 years ago I used to be 3DS MAX guy, but since then I moved full-time to Linux, and that got hard. But, knocking on wood, it seems that blenderistas finally pulled their heads out of their asses, so I hope it will get easier, to do 3D stuff in Blender from now on. So after incredible self torture I somehow managed to get Blender's MD3 exporter working and did some really shitty "surface patches" (terrain like) and used "-" texture in map instead of +-0.01 unit trickery you suggest (walls are thus transparent). And it works ... kinda. Doom editors complaint about missing texture on such walls ("-") but at least I eschew useless redraws and don't have to fuck around with positions (z-wise form doom wall normal). Maybe I should try "TNT1"? @ketmar would there be some other way how to make "HOM transparent" 1sided walls?

 

Now where I hit first tragic limitation is this: shitty doom thing naming scheme - doom sprite names are very limited. Keep in mind this was just research prototyping stage (I don't get anywhere with my prototypes though), and I already gave up. I wanted some "3dwall" reusability, so I came with this idea in my head: I will make several "wallmodels" (as I call them) with multiple sizes and shapes of walls. Then I will place them along my "inviso" 1sided walls to give illusion of detailed rocky sides. The problem is that I would need several dozens of such models and each one eats a slot (as a thing) in dooms sprite table. Even if I use only "single frame" thing to anchor the "wallmodel" to, organization of these things was quickly getting unmanageable, even at just 12 "wallmodels". I had to keep 1:1 "map" between actual md3 model name I wanted to use, thing ClassName and shortened thing name (eg. WLMD01), and this was becoming confusing really quickly ... so I gave up. I wish doom had "misc_model" or rather "Thing_model" (that would allow to pick md2/md3 (and skin at least) arbitrarily)? I don't know @ketmar do you think something like that would be possible (or even is already)? Using DECORATE for these structural "mapmodels" seems like really wasteful way to go about it. So for now conclusion is: "unrealistic".

 

On 3/11/2021 at 3:46 PM, ketmar said:

see? people still recommend to abuse vanila rendering bugs instead of using Boom specials. there is simply no way we could convince mappers to use something that will make the lives of sourceport devs easier! 

Okay I understand his trick making top and bottom part of a wall for crude multitexturing - are you telling us there is a way to achieve same effect without the helper sector, just on pure 1sided wall? Here with it!

 

22 hours ago, Remilia Scarlet said:

but god I love the lighting in k8vavoom.

Each screenshot looks better and better :)

 

[3t0]

On 3/11/2021 at 3:24 AM, Mr.Rocket said:

I'll push out a simple form of Doom geometry in means to replicate a Quake1 world if you'd like? 

It won't be perfect, but would be the base concept, however would be much so in short a reincarnation.

I am fully aware that that is possible already with 3d sector/floors. Problem is too much of such geometry makes modern dooms slow :(.

[Muusi]

When K8 Vavoom gets proper controller support, please for the love of god consider adding in rumble support too :P

[ketmar]

@Muusi it all depends of the controller i'll get. so far i have none (and it is unlikely to change), so... ;-)

[ketmar]

6 hours ago, 3t0 said:

Okay, this sounds seriously cool, now is there some ACS or LineAction that allows one to flip/assign/unassign midtexes? There has to be :D !

sure. it is even named `SetLineTexture`. ;-)

 

6 hours ago, 3t0 said:

would there be some other way how to make "HOM transparent" 1sided walls?

it depends of engine and the phase of the moon. generally speaking, this is UB.

 

6 hours ago, 3t0 said:

Okay I understand his trick making top and bottom part of a wall for crude multitexturing

it seems that you're looking at the wrong trick. i meant second one, with missing top/bottom textures. it triggers floor floodfill bug in vanilla. as hw renderers don't use floodfill to render floors, we have to detect and emulate such things. and it is HARD. there is Boom special to set floor and ceiling lighting separately, but who cares, let's keep abusing vanilla bugs.

 

sometimes i want to create db with idarchive map hashes, and simply refuse to run any map that has such bugs, and is not known, or produced after Boom release. (ah, and stop running original id maps too, they're full of bugs! ;-)

[Muusi]

1 hour ago, ketmar said:

@Muusi it all depends of the controller i'll get. so far i have none (and it is unlikely to change), so... ;-)

I have an extra DualShock 4 V2 right here with "ketmar" all over it. Where do i send it?🤣

[ketmar]

4 hours ago, Muusi said:

I have an extra DualShock 4 V2 right here with "ketmar" all over it. Where do i send it?🤣

just keep it until i come to take it, haha, i'm watching y... oops.

 

there is some code to use dpad (can be activated with "-ctrl" cli arg), but it isn't even tested. i just put it there for no reason. ;-)

[Gwarl]

Screenshots from a map I'm working on in:
1. Software renderer (Eternity engine)
2. OpenGL renderer (GZDoom)

3. k8Vavoom

 

This is just one example but basically; k8Vavoom is too bright.

 

I just compiled this port yesterday, sounds great and looks great - other than everything being too bright.

 

I'd really like to see contrast in the dynamic lighting effects and shadows; I imagine this would look really cool but I can't really make my dark sectors any darker wihtout being pitch black on more mainstream renderers.

 

Also the aspect ratio is off. Doom Legacy looks just like this (screenshot not included for comparison since it hijacks my whole keyboard input); the aspect ratio is off, field of view needs to be adjusted but sprites are still squashed, overbright sectors - but pretty dynamic light. Also suffers from a scripting language that isn't Zscript. k8Vavoom's DECORATE support does set it apart however.

 

Long story short can I request a feature to like, have an option to do some kind of non-linear translation of sector lighting, even at load time, such that values below 128 are really just super dark like they are in software - obviously not just like it but man, I need my dark sectors darker. The dynamic lights will look fantastic then.

[Mr.Rocket]

Hi @ketmar, 

I remember you saying something about the bots at some point with the nature of "don't run the bots, something may blowup" etc. :P

But they seem to work pretty well, actually sometimes challenging in DM mode. ~ at least if there's something they don't get their toe stumped on lol. However, is there a way to keep them from stepping on your feet? I donno if it's because I have my skill setting too high or the bots?

 

Edit: @Gwarl, looking nice! ;)

Edited March 23, 2021 by Mr.Rocket

[ketmar]

@Gwarl the light levels are already darkened and not quite linear. i'll take a look, but no promises -- i'm afraid to touch that code, it is quite... strange.

 

as for aspect ratio -- you prolly need to select proper widescreen mode in addition to setting a resolution, because the engine does aspect ratio correction, and it looks ok on my PC. dunno, hard to say, it should work.

 

and thank you for trying k8vavoom! i hope we'll be able to investigate your issue when i finish with 3d polyobjects code. sorry for inconveniences, i simply don't have enough resources to do more than 0.3 tasks at once. ;-) please, ping me later (i think two weeks should be enough) in case i forget.

 

p.s.: i see GZDoom as the one that suffers from a language that is not VavoomC. ;-) because VavoomC was there long before GZDoom got ZScript at all.

 

 

@Mr.Rocket sorry, that code is not even half-finished, and have almost no interesting/useful control knobs. it also may break at any time too. so i'm afraid that what you have now is the best current code can do. the basic idea of automatic pathfinding is ok, but everything else should be completely rewritten. one day i'll return to it. ;-)

Edited March 23, 2021 by ketmar

[Muusi]

4 hours ago, ketmar said:

just keep it until i come to take it, haha, i'm watching y... oops.

 

there is some code to use dpad (can be activated with "-ctrl" cli arg), but it isn't even tested. i just put it there for no reason. ;-)

I'm serious through. Would be happy to donate if that means proper controller support somewhere in the Future👀

[ketmar]

@Muusi i'd be happy (and i don't mind "deanon" at all), but i absolutely believe in our postal service. they will either break, or lose it, for sure. ;-) it will be sad for you to send it only to have it lost.

 

i have a friend with a controller i can borrow, tho. i have a Secret Plan to do that (that's why some controller code even appeared, tbh), just need to catch him, and don't drink too much in the process. ;-) so just wait a little, and your dream may become a reality without you doing anything special for it. ;-)

Edited March 23, 2021 by ketmar

[Muusi]

52 minutes ago, ketmar said:

@Muusi i'd be happy (and i don't mind "deanon" at all), but i absolutely believe in our postal service. they will either break, or lose it, for sure. ;-) it will be sad for you to send it only to have it lost.

 

i have a friend with a controller i can borrow, tho. i have a Secret Plan to do that (that's why some controller code even appeared, tbh), just need to catch him, and don't drink too much in the process. ;-) so just wait a little, and your dream may become a reality without you doing anything special for it. ;-)

Just say the word and i'll absolutely send it to you if you need it. I have so many controllers that losing one won't make a difference.

 

Also, if a DualShock 4 can take me playing (yelling, smashing etc) Tekken on one, it surely can take whatever the postal service can do :D

 

Waiting for updates, i'm a huge sucker for dynamic lights etc and your port looks beautiful!