k8vavoom: no good thing ever dies!

[CBM]

11 minutes ago, ketmar said:

p.s.: as for improved idTech2 — DarkPlaces is basically "GZDoom of Quake1 engines", i believe. it has a lot of features, including realtime lighting and shadows with shadowmaps (written by no other than Lee Salzman of Tesseract fame!).

hey! pretty cool! Maybe my excessive need for stacking floors on top of each other can be satisfied by darkplaces  :-D

[ketmar]

@CBM just in case, i meant that DarkPlaces is one of the most advanced Quake1 engines, not that it supports anything from Doom. ;-)

[CBM]

20 minutes ago, ketmar said:

@CBM just in case, i meant that DarkPlaces is one of the most advanced Quake1 engines, not that it supports anything from Doom. ;-)

Yes I know. But it seems to have a somewhat "active" community.

And Quake 1 BSP maps do support true 3D maps.

[Gibbon]

Probably the best place for darkplaces would be Xonotics version: https://gitlab.com/xonotic/darkplaces

 

After the author of Nexuiz sold-out to game developers (hence why Xonotic was forked) they also forked all dependent code, so they also develop darkplaces.  And they are much better developers than the original author was.

 

Darkplaces' main site is barely updated and the git repo has 'some' activity.  But not on the same level as Xonotic's version (which most people use instead now).

[CBM]

7 hours ago, ketmar said:

there is nothing really special there, normal GZDoom config should work most of the time. the only major missing part is 3d polyobjects, but they are relatively new, and the spec is not even finalized yet (it should be stable, but i didn't declared it "final" for now).

 

ah, and you also have to check dynamic lighting in k8vavoom itself, because it's light formulas are slightly different from GZDoom, so UDB 3d preview with dynlights will not exactly match what you will see in k8vavoom. it is roughly the same, but not exact.

 

still, i don't think that there is any urgent need to add separate k8vavoom support to UDB. i'm planning to submit configs to SLADE (and maybe UDB) later, tho. the only problem is that UDB is simply doesn't work on my box. ;-)

Is there a map that serves as a tech demo of k8vavoom or a list of features? maybe some tutorials?

 

It would be nice with a tech demo map that could be used to show all the different stuff that can be done in the k8vavoom engine... from what I can gather so far it supports this:

 

polyobjects (same as in GZDoom?) and 3D polyobjects (I must study ramillias latest map to figure those out)

slopes

3d floors

dynamic lighting

transparency?

conveurbelts?

scripting

intermediate screens for telling a story

3d models? (but somehow in a different way than in GZDoom?)

voxels??? (are they also just translated internally to 3d objects like in GZDoom?)

no portals, either horisontal or vertical

 

anything Ive missed? Is there a complete list?

 

4 hours ago, Gibbon said:

Probably the best place for darkplaces would be Xonotics version: https://gitlab.com/xonotic/darkplaces

 

After the author of Nexuiz sold-out to game developers (hence why Xonotic was forked) they also forked all dependent code, so they also develop darkplaces.  And they are much better developers than the original author was.

 

Darkplaces' main site is barely updated and the git repo has 'some' activity.  But not on the same level as Xonotic's version (which most people use instead now).

 

nice, I will be sure to check out that version

 

[ketmar]

3 hours ago, CBM said:

Is there a map that serves as a tech demo of k8vavoom or a list of features?

it is mostly on par with GZDoom (except the portals, and stacked sector support is still buggy). the major difference is the lighting. so most of GZDoom expirience applies.

 

3 hours ago, CBM said:

3D polyobjects (I must study ramillias latest map to figure those out)

…or try to take a closer look at the k8vavoom archive you downloaded. the "specs/" directory is not just sitting there to make the archive bigger. ;-)

 

3 hours ago, CBM said:

3d models? (but somehow in a different way than in GZDoom?)

basic GZDoom MODELDEF is supported. the major difference is model scaling/translation: it is not stacked, as in GZDoom.

 

3 hours ago, CBM said:

voxels???

sorry, no voxel support at all.

 

3 hours ago, CBM said:

anything Ive missed? Is there a complete list?

basically, "if it works in GZDoom, and it is not using portals/ZScript/player morphing, then it should work in k8vavoom too". of course, it is slightly more complicated, because not all GZDoom features are supported, but most of the time everything works as expected. and if not, k8vavoom will usually tell you what is wrong, just look at "conlog.log".

 

and VavoomC is not documented on purpose: i DO NOT want people to use it. if somebody can figure out things on their own… well, so be it. but VavoomC is not set in stone, and anything can change at any moment. if somebody will want to write a completely new game using k8vavoom tech, then they'd better contact me, and we'll find a solution. but otherwise DECORATE is the way to go, and if you can't do it with DECORATE… don't do it. ;-)

 

contrary to GZDoom, k8vavoom is not trying to be a general game engine. yes, you can use it to write a non-Doom game, it is at least as extensible and modifiable as GZDoom, but that's not how i see it.

 

don't get me wrong, i have nothing against standalone games on k8vavoom tech. but to officially support that i will have to mostly freeze the development. GZDoom has ZScript versioning due to that, and it adds a lot of maintenance burden. i don't have enough resources to go that way, so VavoomC is not documented, and not meant to be used by modders.

 

note that in GZDoom you extend the engine with ZScript. but with k8vavoom, you have it written in VavoomC. everything except the renderer and some low-level subsystems is done with VavoomC, including the whole playsim with physics. so exposing VavoomC to modders will mostly force me to freeze everything as it is now to keep it compatible with released VavoomC mods.

[CBM]

1 hour ago, ketmar said:

it is mostly on par with GZDoom (except the portals, and stacked sector support is still buggy). the major difference is the lighting. so most of GZDoom expirience applies.

 

…or try to take a closer look at the k8vavoom archive you downloaded. the "specs/" directory is not just sitting there to make the archive bigger. ;-)

 

basic GZDoom MODELDEF is supported. the major difference is model scaling/translation: it is not stacked, as in GZDoom.

 

sorry, no voxel support at all.

 

basically, "if it works in GZDoom, and it is not using portals/ZScript/player morphing, then it should work in k8vavoom too". of course, it is slightly more complicated, because not all GZDoom features are supported, but most of the time everything works as expected. and if not, k8vavoom will usually tell you what is wrong, just look at "conlog.log".

 

and VavoomC is not documented on purpose: i DO NOT want people to use it. if somebody can figure out things on their own… well, so be it. but VavoomC is not set in stone, and anything can change at any moment. if somebody will want to write a completely new game using k8vavoom tech, then they'd better contact me, and we'll find a solution. but otherwise DECORATE is the way to go, and if you can't do it with DECORATE… don't do it. ;-)

 

contrary to GZDoom, k8vavoom is not trying to be a general game engine. yes, you can use it to write a non-Doom game, it is at least as extensible and modifiable as GZDoom, but that's not how i see it.

 

don't get me wrong, i have nothing against standalone games on k8vavoom tech. but to officially support that i will have to mostly freeze the development. GZDoom has ZScript versioning due to that, and it adds a lot of maintenance burden. i don't have enough resources to go that way, so VavoomC is not documented, and not meant to be used by modders.

 

note that in GZDoom you extend the engine with ZScript. but with k8vavoom, you have it written in VavoomC. everything except the renderer and some low-level subsystems is done with VavoomC, including the whole playsim with physics. so exposing VavoomC to modders will mostly force me to freeze everything as it is now to keep it compatible with released VavoomC mods.

well... if the code is open source then there is a way to get documentation on VavoomC and if one has experience coding in C then one is already well prepared :)

 

To avoid future compatibility issues then I guess your are on point by suggesting sticking to decorate for now...

 

but I cant help wonder.. will maps like Freaky Panties IV break in future versions of k8vavoom since it uses a ton of scripting?

 

I'm asking because I was thinking about how FreeDOOM would look if the levels got k8vavoom enhancements similar to what I have been trying to do in GZDoom (with GZFreeDOOM/GZFreePunk). There are still many things in GZDoom I don't know so it would be difficult for me to make a souped up version of the freedoom levels to serve as a GZDoom tech demo... But since k8vavoom has... less features right now... It would perhaps be more feasible to me to learn all there is to learn about k8vavoom mapping and use THAT to make something like a FreeVavoom project (a FreeDOOM ipk3 for k8vavoom)

 

FreeVavoom would also be a name sufficiently different from the FreeDOOM name to avoid giving the FreeDOOM team trouble

 

Still just an idea floating in my head though.

 

Edited November 9, 2021 by CBM

[inkoalawetrust]

14 hours ago, ketmar said:

ah, and you also have to check dynamic lighting in k8vavoom itself, because it's light formulas are slightly different from GZDoom, so UDB 3d preview with dynlights will not exactly match what you will see in k8vavoom. it is roughly the same, but not exact.

 

That shouldn't be much of an issue, to this day UDB does not cast GZDoom's crappy shadowmaps in visual mode, which is a bigger differennce between visual mode and in-game, than there would be with UDB not displaying K8Vavoom's slightly different from GZDoom, lights.

[Redneckerz]

17 hours ago, ketmar said:

well, it looks Good Enough(tm) for me. ;-) external lightmap builder is yet another gimmick that will be used once or twice, and then forgotten. but to support that i have to write a lot of code to convert external lightmaps to fit internal vavoom subdivided surfaces, or invent The Whole New Format for this, and convince tool authors to support it. the idea is interesting, but the amount of work… well, i don't think it worth it.

So nothing from the various variants of Light.exe (Which is basically how they compute that nice lighting seen in AD) would be sufficient?

17 hours ago, ketmar said:

ahem… i failed to decipher the question, sorry. i mean, literally, it's beyond my English.

Would Vavoom be more able to take advantage of lightmaps done through these lightmap compilers being that its less advanced than K8Vavoom?

17 hours ago, ketmar said:

it was explained in some other thread: the only way to do that is to have two different engines, with completely different data structures, rendering, physics, even actor representation, and pretend that it is still the one engine. it will never work right. it may work "good enough" to record short youtube videos in controlled environment, but in the end of the day it won't be a good Doom engine, and it won't be a good Quake engine.

Close, but no cigar. What if (hypothetically) the new engine mimicks behavior exactly, similar to how byuu's SNES emulator worked out so well/

 

15 hours ago, ketmar said:

p.s.: as for improved idTech2 — DarkPlaces is basically "GZDoom of Quake1 engines", i believe. it has a lot of features, including realtime lighting and shadows with shadowmaps (written by no other than Lee Salzman of Tesseract fame!).

There are various advanced Quake derivatives out there - Darkplaces may not even be the latest.

 

Ill never forget that short lived Nexuiz 2010 GDC demo where Darkplaces was demonstrated on PS3 and X360. Illfonic bought a license from id to use the Quake engine, and a license from then LordHavoc to get a license aswell. Ultimately, they shipped with Cryengine. But Darkplaces on console was a short lived reality.

 

Fortunately Wrath may now take its place :)

[ketmar]

12 hours ago, CBM said:

well... if the code is open source then there is a way to get documentation on VavoomC and if one has experience coding in C then one is already well prepared :)

sure, and that's how i learned everything i know about Vavoom too. ;-)

 

12 hours ago, CBM said:

will maps like Freaky Panties IV break in future versions of k8vavoom since it uses a ton of scripting?

it uses only a little amount of VavoomC, and everything else is done with ACS. besides, early adopters get a cookie, and free lifetime support contract! ;-) (no, Remilia, please, i tasted that cookie a little… then a little more… we have only contracts for now.)

 

12 hours ago, CBM said:

It would perhaps be more feasible to me to learn all there is to learn about k8vavoom mapping

there is very little difference between advanced sourceports actually. at least in terms of mapping. if you will stay away from portals, stacked sectors, and mirrors, then the difference is mostly non-existent. (stacked sectors and mirrors are broken in k8vavoom now; they will be eventually fixed, but it's not a high priority, and i want to rewrite some parts of the rendering code first).

 

i mean, you don't have to choose right now, and can either switch later, of even support both engines. i have nothing against GZDoom, k8vavoom and GZDoom are not rivals, and if somebody can support both, than it's great, because players will have more choice. and giving people a way to play maps in the sourceport they prefer is very important, i believe.

 

8 hours ago, Redneckerz said:

So nothing from the various variants of Light.exe (Which is basically how they compute that nice lighting seen in AD) would be sufficient?

there is no "Universal Doom Lightmap Format", and each engine does lightmaps it's own way. algorightms for radiocity tracers are well-known, there's nothing magical there. but most of the code that actually implements those algorithms is not applicable, due to different BSP and other data formats. so one will basically have to rewrite it from the scratch anyway.

 

8 hours ago, Redneckerz said:

Would Vavoom be more able to take advantage of lightmaps done through these lightmap compilers being that its less advanced than K8Vavoom?

lightmapping idea is the same everywhere: multiply texture colors by lightmap. so improving lightmaps quality will automatically make a lightmapped engine look better. there is no difference here between Vavoom and k8vavoom (sans some fixed bugs). ah, and the fact that k8vavoom can at least cache calculated lightmaps, and load them later, so there is some way to give k8vavoom external lightmaps already, but Vavoom can't read lightmaps from disk at all.

 

8 hours ago, Redneckerz said:

What if (hypothetically) the new engine mimicks behavior exactly, similar to how byuu's SNES emulator worked out so well

then it will be called "Chocolate Doom". ;-)

 

8 hours ago, Redneckerz said:

There are various advanced Quake derivatives out there - Darkplaces may not even be the latest.

as far as i know, DarkPlaces was the only one that tried to add more features, maybe sacrificing some compatibility by the way. i.e. basically what GZDoom does. other engines may have several new features added, but mostly trying to stay "true to the original". or dropping the idea of being "Quake engines" at all, and going their own way.

 

but of course, i may be wrong here, i'm not watching Quake scene closely. that's what i know about Quake engines, it can be used as a starting point, but sure, don't take my words as The Definitive Truth. ;-)

[CBM]

1 hour ago, ketmar said:

it uses only a little amount of VavoomC, and everything else is done with ACS. besides, early adopters get a cookie, and free lifetime support contract! ;-) (no, Remilia, please, i tasted that cookie a little… then a little more… we have only contracts for now.)

 

there is very little difference between advanced sourceports actually. at least in terms of mapping. if you will stay away from portals, stacked sectors, and mirrors, then the difference is mostly non-existent. (stacked sectors and mirrors are broken in k8vavoom now; they will be eventually fixed, but it's not a high priority, and i want to rewrite some parts of the rendering code first).

 

i mean, you don't have to choose right now, and can either switch later, of even support both engines. i have nothing against GZDoom, k8vavoom and GZDoom are not rivals, and if somebody can support both, than it's great, because players will have more choice. and giving people a way to play maps in the sourceport they prefer is very important, i believe.

does k8vavoom support surfaceskin? if not, then that may explain why some of the MD3 space marines don't have textures while my OBJ fireballs have, since they just use skin to assign a single texture to a single model

 

is there somewhere where I can get an overview of ALL features present in sourceports and what sourceports that supports what features?

 

that way I will have a roadmap to follow so that I know what I still need to learn in order to have tried all features supported by the more advanced sourceports

 

I agree that choice is important

[ketmar]

2 hours ago, CBM said:

does k8vavoom support surfaceskin?

i don't think so.

 

2 hours ago, CBM said:

is there somewhere where I can get an overview of ALL features present in sourceports and what sourceports that supports what features?

no. i don't even think that such table is possible. first, it will require somebody who knows everything about every sourceport out there, and constantly monitors development of each sourceport. second, it's hard to define even what "feature" is. for example, both GZDoom and k8vavoom have shadowmaps, but it can hardly be called the same feature, so now we already have two port-specific features supported only by the respective ports. and it goes on for many other features too.

[Redneckerz]

On 11/10/2021 at 8:24 AM, ketmar said:

there is no "Universal Doom Lightmap Format", and each engine does lightmaps it's own way. algorightms for radiocity tracers are well-known, there's nothing magical there. but most of the code that actually implements those algorithms is not applicable, due to different BSP and other data formats. so one will basically have to rewrite it from the scratch anyway.

Well, there used to be Gooberman's BSP2Doom, which allowed you to use the EricW-Tools in Doom - Multibounce lighting. It converted Quake data to something Doom would understand before handing it over to a nodes builder.

 

So that's why i feel there is merit - Currently Quake lighting is done on BSP2 format maps, EricW-Tools and Jury Rigged-BJSP Tools are two (and perhaps the only two) toolsets who allow rather advanced static lighting there.

 

How would id's original Light.exe stack up? Is a Quake BSP so inherently different than Doom? Forgive me for asking what undoubtely are foolish things, and partially only fueled by my recent interest in Quake lightmap generation.

On 11/10/2021 at 8:24 AM, ketmar said:

then it will be called "Chocolate Doom". ;-)

But its not the same renderer ;)

On 11/10/2021 at 8:24 AM, ketmar said:

as far as i know, DarkPlaces was the only one that tried to add more features, maybe sacrificing some compatibility by the way. i.e. basically what GZDoom does. other engines may have several new features added, but mostly trying to stay "true to the original". or dropping the idea of being "Quake engines" at all, and going their own way.

 

but of course, i may be wrong here, i'm not watching Quake scene closely. that's what i know about Quake engines, it can be used as a starting point, but sure, don't take my words as The Definitive Truth. ;-)

There are far too many Quake engines on the planet - From DirectQ to QBism to Engoo to Vengeance. Engoo is basically Darkplaces but in pure software, and like Qbism, has integrated colored lighting, on DOS even.

[Pixel Fiend]

Which mods are supported?

[ketmar]

10 hours ago, Redneckerz said:

Well, there used to be Gooberman's BSP2Doom, which

…is a gross hack. very smart, but still hack. and very creative wasting of texture memory by abusing brightmaps as lightmaps. ;-)

 

10 hours ago, Redneckerz said:

Is a Quake BSP so inherently different than Doom?

2D vs 3D, solid vs inverted. everything is different, the only common thing there is the word "tree". ;-)

 

but there is nothing magical in Quake lightmap generators: they are the usual raytracers. any CPU-based lightmap generator does the same, even Vavoom built-in one. and Strife VE, by the way. there is no need to jump through hoops trying to somehow reuse Quake tools output, the very same tools can be natively created for Doom.

 

the problem is not the tools themselves, but standardised lightmap support in sourceports. without the accepted standard and support from most sourceports with HW rendering, there is simply no reason to invest any time into such tools.

[ketmar]

2 minutes ago, game said:

Which mods are supported?

Brutal Doom is not supported, and will never be. Project Brutality too. case closed, i guess.

[Gez]

Don't you have a "lite" version of Brutal Doom built-in?

[ketmar]

1 hour ago, Gez said:

Don't you have a "lite" version of Brutal Doom built-in?

dunno, i wouldn't call "more blood, and two optional weapons" "BD Lite". more like "ketchup lite" and "small weapon mod".

[Gibbon]

It basically already is right.  You have blood, fancy effects etc..

[Redneckerz]

3 hours ago, ketmar said:

…is a gross hack. very smart, but still hack. and very creative wasting of texture memory by abusing brightmaps as lightmaps. ;-)

But it does allow for Quake tools to be used, which i think is kinda neat.

3 hours ago, ketmar said:

but there is nothing magical in Quake lightmap generators: they are the usual raytracers. any CPU-based lightmap generator does the same, even Vavoom built-in one.

What's that one called, the lightmap generator for Vavoom?

3 hours ago, ketmar said:

and Strife VE, by the way. there is no need to jump through hoops trying to somehow reuse Quake tools output, the very same tools can be natively created for Doom.

Strife VE uses DLight (As does Doom64 EX) but it is tailor made for Strife VE. It has a specific set of limitations. There isn't much use of it because it relies on GL-Nodes. It does form the basis of ZDRay, which is currently in the works to (hopefully) implement official lightmap support in GZDoom and in UDB, combining a light baking tool with ZDBSP.

3 hours ago, ketmar said:

 

the problem is not the tools themselves, but standardised lightmap support in sourceports. without the accepted standard and support from most sourceports with HW rendering, there is simply no reason to invest any time into such tools.

That i can agree with. What is so common place in Quake isn't in Doom. But i would have expected (somehow) that over the years someone would port light.exe over as an experiment.

[xX_Lol6_Xx]

I have the port a try, it was a bit harder to set up than the other ports, but after that the game looked and played very good 

[ketmar]

1 hour ago, Redneckerz said:

What's that one called, the lightmap generator for Vavoom?

it is called "Vavoom engine". ;-) lightmapped renderer doesn't take its lightmaps from some magical dimension, it is basically the same raytracer that is used to create Quake lightmaps. only it is built into the engine.

 

1 hour ago, Redneckerz said:

But i would have expected (somehow) that over the years someone would port light.exe over as an experiment

and Janis did exactly that decades ago, and put it into Vavoom engine. nobody payed any attention.

 

 

@Lol 6 thank you! glad you liked k8vavoom!

[ketmar]

by the way, i'm working on a "maintenance build", with some bugfixes. i also added damaging floor decals, so it is possible to implement some acid weapon or aliens with poisonous blood without spawning invisible actors. damaging decals can optionally damage monsters/players, and it is possible to set how leaky protection suit will be for them.

[Redneckerz]

3 hours ago, ketmar said:

it is called "Vavoom engine". ;-) lightmapped renderer doesn't take its lightmaps from some magical dimension, it is basically the same raytracer that is used to create Quake lightmaps. only it is built into the engine.

 

and Janis did exactly that decades ago, and put it into Vavoom engine. nobody payed any attention.

So it integrates Light.exe? I am intriqued :) Is there any documentation regarding this?

 

It sucks nobody cared about that, but then again Vavoom is an engine juxtaposed to accept Doom content. But it is interesting nonetheless!

 

[ketmar]

On 11/12/2021 at 7:53 PM, Redneckerz said:

So it integrates Light.exe? I am intriqued :) Is there any documentation regarding this?

there is no other way to create lightmaps, you have to raytrace them. there is no real difference between doing it as a separate step, or just after the map is loaded. what documentation are you interested in? there is no magic, Vavoom actually does what Quake lightmap builder do after loading map geometry. exactly the same: it subdivides all surfaces to smaller rectangles for better lightmap packing, and then raytraces all the lights. this once was the case of long map loading times, by the way — exactly because Vavoom had to recalculate all lightmaps from the scratch on each map load. i added lightmap caching to k8vavoom, so if raytracing takes significant time, k8vavoom will save created lightmaps in cache file.

 

k8vavoom also does full raytracing for dynamic lights, that's why imp fireballs and such can cast shadows even in lightmapped renderer. plus, k8vavoom rebuilds affected lightmaps when some static light was moved (or door opened, etc.), to keep the lighting up-to-date. it can do it incrementally (by default it tries to spend no more than 10 msecs per frame on lightmap rebuilding). so it's even more advanced than Quake here, because original Quake never rebuilds static lightmaps (that's why you can't get nice lighting effects from opening doors in it). of course, it's not Quake's fault, there simply were no CPU resources to do that in real time back then.

 

p.s.: that's also why i'm not so fond about external lightmap builder. who will rebuild lightmaps on geometry change? ;-)

Edited November 14, 2021 by ketmar

[ketmar]

@ENEMY!!! so i was using wall normal instead of wall itself to calculate bouncing angle. lolsodumb.

[ketmar]

maintenance build is planned at the end of this week. lol, it already got over 20 fixes. i am almost reached AAA quality, the only last step left is uploading totally broken builds as the first releases.

[camper]

On 11/9/2021 at 9:44 PM, CBM said:

THAT to make something like a FreeVavoom project (a FreeDOOM ipk3 for k8vavoom)

You don't have to make a dedicated iwad, the K8VAVOOM is very flexible in that sense. It is enough to take an empty IWAD from Freedoom version 0.5 to be able to run, for example, the file q2doom.pk3. Of course, only the level with textures will start and there will be no weapons, but using add-ons, you can separately load packs of weapons or monsters, or textures.

 

Hello everybody!
Hello ketmar!

[CBM]

28 minutes ago, camper said:

You don't have to make a dedicated iwad, the K8VAVOOM is very flexible in that sense. It is enough to take an empty IWAD from Freedoom version 0.5 to be able to run, for example, the file q2doom.pk3. Of course, only the level with textures will start and there will be no weapons, but using add-ons, you can separately load packs of weapons or monsters, or textures.

 

Hello everybody!
Hello ketmar!

I know, but the purpose would be that it would serve as a techdemo. However I have abandoned that idea for now anyway. I have too many projects that I need to finish

[CBM]

3 hours ago, ketmar said:

maintenance build is planned at the end of this week. lol, it already got over 20 fixes. i am almost reached AAA quality, the only last step left is uploading totally broken builds as the first releases.

there is no such thing as a bug free build :-)