|
Post by 3t0 on Jun 22, 2022 20:42:47 GMT -5
Sorry ketmar I will use really big purple font next time . I promise. Man @gibbon, your github is treasure trove of stuff. I just compiled ReGLOOME: there are a few warnings here and there on my systems, would you be interested in report logs ? I also wanted do discover the schism between here and doomworld and boy have I lost time in threads with interesting reads. Never mind, let us return to the k8v port. Because I got Ultimate Doombuilder running on Void, I kinda tried mapping again, but stuff is still missing a lot of what I myself would want and need, and I am pretty down because of that. Anyway UDB always complained about nodebuilder exec missing so I went without nodebuilding altogether some months ago. Haven't looked at maps but I guess in that case NODES lump is empty (note to self: check it with Slade). This means NODES-less map really are fine as I thought. I love Slade (okay I also hate it) but I really want 3D floors, even with slopes, and vertex height tris sectors and at the pace Slade is developing these features seem to be a fucking pipedream. Also it is bound to wxWidgets which are objectively shit. It seems sir revived 3d-floors patchset so maybe it will finally get fixed but I am not so sure anymore. Still native linux binry would probably be much better than UDB ? Not sure... Back to nodebuilding topic thoug, so modern k8v map without NODES is fine, as I assumed from progress bars. Now, as I said, I did some re-reading on nodebuilders (remembering oldschool times) and it seems that major issue was missing floating point precision, as you pointed out. Last time I dove in k8v all the structs related to map used float, so I realized that internally k8v uses floats instead of fixed points anyway (I guess GZ does the same?), so after reading nodebuilder wiki and your reply it make sense that "normal" NODES are useless to it (k8v) and it makes sense use new builders. What makes me confused is that AJBSP is touted as much better than ZDBSP (and I assume both ones that are integrated into k8v are basically "internal" amalgamated forks by now, quite diverting from original standalone releases). Why is ZDBSP still present, if it is not so good? Couldn't it be removed? Or is included just because there are maps at which ZDBSP is simply better than AJBSP?
|
|
|
Post by ketmar on Jun 23, 2022 4:43:44 GMT -5
Haven't looked at maps but I guess in that case NODES lump is empty yeah, it is zero size in this case. at least GZDoom and k8vavoom will rebuild invalid nodes (i thing EDGE too, but i didn't checked). actually, i believe that most advanced sourceports can run "nodeless" maps. I love Slade (okay I also hate it) but I really want 3D floors, even with slopes, and vertex height tris sectors and at the pace Slade is developing these features seem to be a fucking pipedream. Also it is bound to wxWidgets which are objectively shit. i like Slade editor too. and wxWidgets… let's say that i prefer running windows Slade binary in Wine, if i have to. ;-) it make sense that "normal" NODES are useless to it (k8v) and it makes sense use new builders. actually, vanilla-type nodes are useless for any port with hardware rendering, because vanilla didn't bothered to create proper floor polys, it was interested only in seg sorting. so GL nodes were invented (essentialy the same BSP, only nodebuilder ensures that each subsector is a convex polygon). but they are still fixed point, so i decided to not bother. ;-) What makes me confused is that AJBSP is touted as much better than ZDBSP it is mostly "better tested". i like its code, and i'm using it myself, so it is "developer's choice". actually, ZDBSP is much faster, and does better job with buggy/tricky maps sometimes. but i remember it creating strange/broken BSP trees sometimes. it was a long time ago, and maybe it was a bug in k8vavoom renderer, but i don't trust ZDBSP since that time. ;-) also, ZDBSP was "quick-and-dirty" port, done only to process UDMF maps before i tweaked AJBSP. (and I assume both ones that are integrated into k8v are basically "internal" amalgamated forks by now, quite diverting from original standalone releases). this time i did almost no changes there, mostly removed some unused code, and tweaked some constants in AJBSP to make it work better with UDMF maps. they're still mostly "external code": the engine emulates map loading to the respective builder data structures, calls it, and then gets the built data. Why is ZDBSP still present, if it is not so good? Couldn't it be removed? but why not? it doesn't cost me a penny to keep it there. and yeah, it may create a better tree for some ancient maps with exploits. i honestly forgot what those maps are, but i've seen them. ok, let's be fully honest here: the real reason to not use ZDBSP is much simplier -- i don't trust ZDoom code. I'm ok to run Andrew's code without reading each line there, but not ZDoom. it's not about ZDoom code doing something destructive, of course, it won't format your drive or something. it is just… sloppy. so i defaulted to Proven Andrew Quality. ;-)
|
|
|
Post by meapineapple on Jul 10, 2022 14:10:46 GMT -5
Hi ketmar and all, I'm interested in experimenting with k8vavoom mapping. I've always felt starved for better dynamic lighting options than other ports have provided. However, I've run into a small obstacle: I haven't managed to find documentation on configuring mapping tools like Ultimate Doom Builder to know about k8vavoom's things, linedef actions, etc. or even an explanation of what thing IDs or linedef actions might affect lighting behavior. I'm not sure if I'm just being dumb and have missed the obvious, or should just be using the same lighting things as with GZDoom, or what. But it would be very helpful if information like this were included in places like the k8vavoom build downloads, and the original forum post.
Thanks!
|
|
|
Post by ketmar on Jul 10, 2022 20:06:02 GMT -5
meapineapple, yeah, it is mostly GZDoom-compatible, so GZDoom config should work. there is "specs/k8vavoom_pointlights.txt" file that describes some additional arguments to point light things, but you don't need it for most normal maps. just use GZDoom dynamic lighting things, and assume that most decorations that should emit the light (candelabras, etc.) do it (again, like in GZDoom). there are new things for 3d polyobjects, though, but they are described in "specs/3dpobj/". i'm not using UDB (can't even run it ;-), so i can't create config for it. but if somebody will do that, and contribute the config with the brief instruction how to install it, i'll happily include it into repository and new builds. thank you for deciding to try k8vavoom mapping, and feel free to ask any questions, i'll try to answer them as best as i can. ;-)
|
|
|
Post by meapineapple on Jul 14, 2022 15:55:49 GMT -5
I'm sorry to say that I'm not satisfied with the lighting features after all. There is often light bleeding on edges or corners of sectors where shadows are not applied as expected, this was the most immediate problem for me. Tinted lights also do not interact realistically; when you place several red lights close together, the room will be lit white. (Maybe these were problems with my video settings? Though I tried many different options.) The tinted lights issue might have been mitigated if the range and intensity of a light could be assigned separately, but this does not seem to be the case? And, as with GZDoom, there does not seem to be an outdoor directional light available, nor area lights, which I feel are meaningful shortcomings if lighting specifically is meant to be a draw.
I also wasn't able to get line portals to work, which are an important tool when dealing with more complicated 3D level geometry. (After interactive or static line portals didn't seem to be recognized, I didn't try sector portals.)
I think it's wonderful how much further k8vavoom takes lighting than other ports, but it leaves me wanting so much more. Realistic lighting is such an important part of atmosphere and aesthetic, and I think taking things a few steps further could bring a lot to Doom and really set a port apart.
It's the ceiling I keep banging my head against, trying to further myself as a Doom mapper. What's the point in creating yet another flatly, unconvincingly lit cave, or castle, or town, or hellscape, or techbase, or whatever, that is barely aesthetically distinct from a dozen maps I already made before, in the many years that I've been mapping for Doom? I need light, damn it.
Graphics cards with GI raytracing support are finally going down in price, and I finally picked one up for myself. It would be seriously wonderful to make use of it in Doom. Even if my own graphics programming skills are probably not up to the task, I have to remain hopeful that one day it might become a possibility. Is it at all feasible that this sort of thing might be in k8vavoom's future?
|
|
|
Post by ketmar on Jul 14, 2022 23:51:59 GMT -5
There is often light bleeding on edges or corners of sectors where shadows are not applied as expected that's simply how shadowmapping/lightmaps work. there is a tradeoff between quality and speed, as usual. idTech1 simply wasn't designed for such tricks, so the engine has to do a lot of work that could be heavily optimised in the engine that was designed with such lighting in mind from the ground up. alas. also, using huge lights (with big radius) to lit the scene will cause heavily artifacting. that's, again, due to limited shadowmap resolution. Tinted lights also do not interact realistically; when you place several red lights close together, the room will be lit white. i'd like to see a test map with this bug. lights are additive, so if your lights are red, they cannot get to white, there is simply no G and B components for that. but if you have some non-zero G and B, then yes, placing a lot of lights close to each other will cause distortions. this is, again, due to simplistic lighting model. The tinted lights issue might have been mitigated if the range and intensity of a light could be assigned separately, but this does not seem to be the case? those things are not independent. light intensity falloff formula is not linear, and it determines the radius. it may be possible to allow setting smaller radius for "hard cutoff", but it will mean additional checks in shaders, and shaders are so complex already that some older GPUs simply cannot run them. that is, i don't think that benefits of having such option will outweight the loss. And, as with GZDoom, there does not seem to be an outdoor directional light available directional lights are planned, but not implemented yet. trying to fit them into the current lighting code will cause a major speed loss and heavy artifacting (due to limited shadowmap resolution). to have them work better, something like cascaded shadowmaps need to be implemented, and it's a huge task. i am in R%D phase now, trying various approaches to find the one that will work more-or-less satisfactory. i don't think that i will implement this. too complex thing, sorry. I also wasn't able to get line portals to work portals are not supported, and will never be supported, sorry. they may be a convenient thing for mappers, but they simly don't fit the engine architecture. GZDoom is fighting with portal bugs to this day (and will continue to do so) exactly because portal implementation in idTech1 is a gross and messy hack, even by idTech1 standards. I think it's wonderful how much further k8vavoom takes lighting than other ports, but it leaves me wanting so much more. thank you. but i feel that i failed to coimmunicate project goals (heh, i never explicitly did that, mea maxima culpa). k8vavoom is not meant to be graphically advanced engine, nor the engine for modern highly-detailed hyperrealistic maps. the lighting is a bonus, not a selling point; k8vavoom lighting features are meant to make otherwise normal Doom maps looks slightly better, not to completely redefine Doom look. that's why i don't have GZDoom-like PBR/materials system, for example, and there are no plans to implement it. Realistic lighting is such an important part of atmosphere and aesthetic, and I think taking things a few steps further could bring a lot to Doom and really set a port apart. there is a huge problem with engine improvements: once you'll have a very advanced engine with a renderer on par with other 3d engines out there, the game will fall apart. not because of speed, but because of style conflict. Doom textures are low-res, Doom enemies are sprites, Doom geometry is very simplistic. if you'll improve only one of those things, other things will start looking out-of-place. i feel that current k8vavoom lighting almost crossed the line beyond which it will make more harm than good, and making major improvements will turn the engine into something i never planned to do. It's the ceiling I keep banging my head against, trying to further myself as a Doom mapper. What's the point in creating yet another flatly, unconvincingly lit cave, or castle, or town, or hellscape, or techbase, or whatever, that is barely aesthetically distinct from a dozen maps I already made before, in the many years that I've been mapping for Doom? I need light, damn it. …and i can play Yet Another Silly Old TechBase any time i see it. ;-) i understant your desire to grow as a mapper, though. sadly, i don't think that k8vavoom can help you there: supporting such complex things simply out of the project scope. sorry. Is it at all feasible that this sort of thing might be in k8vavoom's future? i barely have money to buy food, so any hardware upgrades are out of question. ;-) but even if i'll be able to upgrade my hardware, there is no way k8vavoom will get GI, or raycasting, or some other "modern feature". it is, again, out of the project scope: idTech1 architecture is very hostile to modern GPU tricks. and i'm also not sure if such features has place in Doom. it's really a question of tastes, but many modern maps don't feel like Doom for me anymore. and k8vavoom is the engine to play Doom, not a general-purpose game engine. at least that's how i see it. sorry if this post was disappointing, but i think that it's better to say it in clear instead of promising the things i will never do. i never explicitely wrote about that (my bad!), but i have the clear vision for k8vavoom project, and some things simply don't fit. i should create a document describing what to expect from k8vavoom, and what will never be added. but i HAET writing documentation… (sighs)
|
|
|
Post by meapineapple on Jul 15, 2022 9:49:46 GMT -5
I understand about this not being your goal with k8vavoom, and about limitations with the shadowmapping. Though I am disappointed in general with the state of lighting in Doom ports, I didn't have any real expectation that k8vavoom would change just for me, and am not disappointed in that regard. If it's feasible, I would maybe suggest giving those with more powerful hardware the option to increase the resolution or accuracy of shadowmaps? But of course I understand that this is not as easy as flipping a switch. My lights indeed were not pure red, but had a slight orange tint, with nonzero values for the green and blue color channels. And while I understand that setting light intensity and range independently is not necessarily realistic, the ability to do this is one of the most important tools available for creating convincing lighting and atmosphere in Source maps: developer.valvesoftware.com/wiki/LightIf only those few things were to change, even though it would not be everything I wanted, I can say that for me it would be enough to tip the scales and make me much more interested in k8vavoom than GZDoom, or any other port I know of. There is only one thing that I would argue with: I don't at all agree that realistic lighting is incompatible with low-resolution textures and sprites, or with simple geometry. I think that lighting is by far the most important part of making a 3D scene immersive and visually interesting, to the point that everything else barely matters. A scene can be all solid colors and simple shapes, but if the lighting feels realistic then the scene will feel realistic too. You can read about this as it pertains to VR, where developers are often making pragmatic decisions to compromise other forms of visual fidelity just to allow more realistic lighting: www.siliconstudio.co.jp/middleware/enlighten/en/blog/2017/20170118/If you take a less complex scene but you illuminate it carefully, with well-placed light sources of considerate colours and intensities, it can be extremely impactful. This is especially important to bear in mind for virtual reality where huge polycounts and complex textures may be too expensive to handle.I did a little bit of mapping for the game Prodeus, which was delightful, and some of the most fun I've had with mapping. It's a "boomer shooter" very clearly inspired by Doom. It uses low-resolution textures, like Doom. The enemies are stylized as sprites, and the geometry is similarly uncomplicated. And its lighting tools were very satisfying to work with, and gave me a great deal of power and freedom in creating a distinct atmosphere for different areas. (Even if I was left overall somewhat disappointed, at the time, by the limited vanilla texture set and the inability to add new textures.) I think the game looks amazing. I really wish that I could create a similar experience, with Doom gameplay and assets. Here's a video of that map I made for Prodeus: youtube.com/watch?v=teokCnqDwS4&t=1185sAnyway, I really appreciate the detailed reply. Thank you for that.
|
|
|
Post by ketmar on Jul 15, 2022 11:02:37 GMT -5
I didn't have any real expectation that k8vavoom would change just for me, and am not disappointed in that regard. i'm always open to discussion; yet i may be very stubborn defending my views ;-). for example, PBR/materials is a no-no (it is impossible to implement it in the current renderer/texture manager, and rewriting those things is a lot of hard work for basically very small amount of maps; i simply don't have enough resources for that). but sometimes i can change my mind about other things. ;-) If it's feasible, I would maybe suggest giving those with more powerful hardware the option to increase the resolution or accuracy of shadowmaps? it is already possible, look at "options->video options->shadowmap options". you can set shadowmap size there, up to 1024x1024. but the artifacts will still remain, this is just how the algorithm works. i have to round coordinates to avoid "piter panning"/moire, and it will inevitably create some artifacts at slopes/corners, alas. And while I understand that setting light intensity and range independently is not necessarily realistic, the ability to do this is one of the most important tools available for creating convincing lighting and atmosphere in Source maps: developer.valvesoftware.com/wiki/Lightthe problem is, again, in the code. that's how lighting formulas work in the engine. interbally, the light has a radius, and RGB intensity, though. you can look in share/basev/common/basepak.pk3:fxdefs/, for example: there, lights are defined by the radius, and the color (as floating point value). but light falloff formula is hardcoded, and cannot be changed (at least for now). There is only one thing that I would argue with: I don't at all agree that realistic lighting is incompatible with low-resolution textures and sprites, or with simple geometry. to have more realisting lighting, it is necessary not only to fix the formulas (and rewrite the renderer), but introduce PBR, to have ambient/diffuse/reflection/normals/etc. matherial properties. this is simply not possible with the current rendering architecture of k8vavoom. i *may* add that feature if i'll ever rewrite some parts of the engine, but don't hold your breath, it's not even in my TODO list yet. ;-) idTech1, as i mentioned earlier, is very hostile to modern GPU-based rendering techniques. while i have some ideas how to make it better, it is a huge amount of work (at least several years of hard work, and i prolly still underestimating here). i will never be able to do it given my limited resources (sadly, i am the only k8vavoom dev with enough knowledge to do it, and i'm living in Ukraine, which doesn't have a good living/working conditions these days ;-). i'm slowly improving some parts of the engine, but… I think the game looks amazing. I really wish that I could create a similar experience, with Doom gameplay and assets. it is heavily using PBR, so you will have to create matherials for all textures anyway. this is a lot of work, basically retexturing the game from the scratch. ;-) Anyway, I really appreciate the detailed reply. Thank you for that. i'm always happy to explain my reasons for (not) doing something, i want people not to simply accept them, but to understand why something is done the way it's done, or why something is not possible/very hard. so ask any questions you like, i'll try to do my best answering them. tbh, quite often i'm getting new ideas while explaining the things to others, and some features appeared because i explained why it's not possible, and then suddenly got an insight: "hey! but it IS possible!" ;-)
|
|
|
Post by 3t0 on Jul 19, 2022 20:27:57 GMT -5
I understand about this not being your goal with k8vavoom, and about limitations with the shadowmapping. Though I am disappointed in general with the state of lighting in Doom ports, I didn't have any real expectation that k8vavoom would change just for me, and am not disappointed in that regard. I feel you and your pain. The thing with k8vavoom is, that is very interesting engine. Of course this is due it being the fork of vavoom, which already was, for decades, odd one out among doom engines (with some bumpy road and drama back in the day). But, then there is ketmar and id0 (shoutout), who are very interesting non-conforming individuals themselves - not sure where are you from, but if you are from western hemisphere, you could easily clasify them lunatics (not in a bad way). You could clasify me that way for sure. So while it is an interesting engine, the problem is, it might not be engine for you or for what you want to do. So what you want to do? That is the really important question to ask yourself. Not sure how old are you, but both ketmar, me, and I presume many others here are reaching 40s. Heck I hear Graf Zahl is in his 50s. Sometimes I wonder about Randy Heit, how old is he/she (not sure, I heard some rumor there was some pronouns change). We were there before there were game engines. Heck, we there before there were mobiles and before there was even internet (even though it existed - it was fringe space-level technology nobody seen - only heard about). Many of us remember world without internet - yet we still had computers. What is worse we fell in love with them and thus lost our lives to them: even single computer is digital world so wast, that it can consume you whole body and soul forever and ever. I always laugh at a "welcome mere mortal" introduction in Hexen (going from memory here, but I am pretty sure daemon says something like that) - so motherfucking fitting the case. So, if each computer is an full universe (and a reverse time (and time dilation) machine - my personal opinion) and that is true even at 200mhz and 256 megs of RAM, what happens now when we have gigabytes and multi-cores? And what happens now, when you connect these monstrous things into vast, and by now interplanetary, network? Internet? Multiverse? All are silly names to call this weird warping multifaceted multidimensional fractal construction that emerges from these lowly and boring layers built on top of physical register sets and infinite herds of finite and infinite tables. Sorry for the sidetracking but why I am talking about it? Because Doom is product of that time, the time "before". It is very specific artifact, bound by dimensions of the time it emerged: of 32bit 486 cpu, of 32 bit flat memory model, of nullmodem and network transports being still closer together in speed then they are now. It's very interesting technological point in human history. All these factors inform its' architecture - and sets some of these things in stone (granite) and make them virtually unchangeable. That is a problem, it has with modern generations. And it is also akin to old single cylinder 2-stroke engine. Completely inadequate. Modern single cylinder 4-stroke engines beat the shit out of the most 2-strokes any time (besides very specific reasons where 2-strokes still reign supreme to this day). Now you seem like you would be "kinda into 4-strokes" and if that is the case, then the path forward for you is: Quake. There there is at least some lightning model proposed from the beginning. But I have a hunch you don't really like messing with carburetors, these are analog devices after all, ones that go out of tune ever so often and need delicate balance and tuning (half a screw turn forward, quarter screw turn back, often by hunch - sometimes for hours) to work again reliably, art lost on many youngsters these days. What you seem to really want is fully computer controlled direct injection at specific timing intervals, where ECU computer knows exactly in what relative positions to each other all parts of an engine, crankshafts and pistons, are. Where you can microdose or even turn off each cylinder as you need, to control every aspect of the run. So what to take away from this: - vanilla doom
- design: ancient 2-stroke, carburetor, all analog
- experience: greasy and shitty, breaks even when you look at it wrong
- love needs: it's need for your love is infinite
- k8vavoom
- design: modern specialty two stroke, direct injection, multimix, thermal fuses
- experience: super reliable, but you have to know it, like really
- love needs: requires lots of your love and deep understanding
- quake
- design: by now bog standard optimised 4-stroke gasoline with analog distributor
- experience: almost maintenance free, until main revision time arrives
- love needs: needs lots of love, but it is much more forgiving then the two above
- unity/unreal
- design: modern hyper-optimised 4-stroke diesel with digital ECU and high pressure injection and twin-turbo
- experience: virtually maintenance free, when it breaks you have already bought a new car
- love needs: does not need any of your love - really, you just "rape it" like virgin hentai elf-girl with your ideas and "just do with it the things you want to do" - no limits/no stops
Or said other way: - Doom is just pile of gimmicks, celeverly strung together in such a way, that it gives you the illusion of 3d space - but it really is just random bag of tricks. Stretch any trick too thin and it breaks - not comfy at all.
- Quake is actually an usable and relatively comfy 3d space - like for real.
- Prodeus is just different bag of tricks - you go out of your way to emulate shitty Doom in a very comfy 3d space.
Hope the point got across. So now it is perfectly valid for you to conclude that you have no love for k8vavoom - expand yourself in Prodeus (and Unity) - trust me this will be much less painful, time better spent. Will give you actual gamedev experience, make you employable if that is you aim. Disregard if this doesn't apply. If you are stubborn and you like 3D spaces so much (sector portals, linedefs portals) and are not completely rigid by now, get a Trenchbroom and go try Quaking - it's fun! I promise. You can go nuts vertical. Now if you really are a stubborn masochist and k8vavoom cupid hit you heart forever, learn to swim: - Regarding verticality and complex 3D structures:
- just build them from 3D sectors - k8vavoom is very 3d sector optimized - and if ketmar gets to it one day - it might end up being most 3d floors optimized doom port there will ever be
- yes I know, this is nothing for pussies - when mapping for gzdoom its easier just to draw multiple "mini-maps" (building story layouts) and link them through floor/ceiling portals - this wont work for k8v, you need to be real man here - but if you scratch your head hard enough and use ultimate doom builder, you can get quite a lot of crazy shit done
- use/abuse 3d polyobjects - I have not played with these yet, but there are some crazy examples here and on doomworld and on youtube - seems like goto "3d thing"
- Regarding light model:
- think of it as completely bogus model - treat is as having it's own magic logic - experiment, experiment, experiment
- always err on smaller side: use small lights, i.e. small light sources, dimmer light sources, in fact always get as low as possible
- less is more - worse is better: use less "real" lights, use fakery more
- you can fake a lot with classic sector light especially skylight - why throw out the baby with bathwater? unless you want monsters to have strong shadows outsides, why bother - you won't be emulating day night/cycle or will you?
- if you are mad you can fake some light effects with textures
- Regarding everything else:
- accept "the k8vavoom way"!
- learn to perceive the k8vavoom style:
- good study of "style" is Quake community and their great mods, mainly: Arcane Dimensions and Alkaline - I suggest you strongly to play them
- AD and Alkaline could have gone bonkers with silly Darkplaces engine features and end up being poor clones of poor modern designs in poor engine - instead they went full Quake style and result is a miracle
- AD and Alkaline feel more Quake then actual Quake itself - it's hard to describe, but it is a fact - it's all about models style (there are dozen new enemies, yet they feel Quake native as fuck), texel density, very carefully crafted paletted textures
- when you return to vanilla Quake after AD/Alkaline you see exactly what was done and how tastefully it was done - I believe there is similar style dimension that is k8vavoom's own, somewhere on on the middle ground between Quake and Doom, leaning more towards Doom - there are colored lights and particle effects, but there are no "nextgen" effects
- thus accept the texture model (palletes,texel sizing)
- accept the mapping model (k8v preference for 3d floors)
- give up on zscript
- use and report bugs in DECORATE
Hope this gives you some good thinking points.
|
|
|
Post by ketmar on Jul 19, 2022 23:08:01 GMT -5
Doom is just pile of gimmicks, celeverly strung together in such a way, that it gives you the illusion of 3d space - but it really is just random bag of tricks. Stretch any trick too thin and it breaks - not comfy at all. the best idTech1 explanation i've ever read.
|
|
|
Post by meapineapple on Jul 20, 2022 5:57:40 GMT -5
So now it is perfectly valid for you to conclude that you have no love for k8vavoom - expand yourself in Prodeus (and Unity) - trust me this will be much less painful, time better spent. Will give you actual gamedev experience, make you employable if that is you aim. You make a lot of good points 3t0, but I'm afraid you missed the mark on me. I have actual gamedev experience. I am employed as a software developer, in another field. I'm not quite as refined in age as you and ketmar, but I'm not as far behind as you might think. My problem is that I'm in love with Doom's gameplay design and balance. Specifically the weapon and item and monster selection of Doom 2, and the tools given to a mapper to create interesting encounters, are as close to perfect as any FPS game I've ever played. I really love the visual style, even if after so many years working in it I'm starving to expand a little. And Doom has such an enduring community. It has its rough spots, but it's still a lot better than any other gaming community I've participated in. The important thing is that if I publish a Doom map today, I can be practically certain that at least a few people will play it. I even get to watch many of those playthroughs. That is a rare thing, for a level designer, and precious. I've mapped and modded for a lot more games than just Doom. But I still have kept coming back to it. See, Prodeus has just about the most enjoyable 3D mapping tools I've used for any game so far, but (in my opinion) its gameplay kind of sucks. It borrows the aesthetics of Doom without understanding what made its gameplay timeless. The weapons feel clunky. The monsters feel like barely distinguished bullet sponges. It's not great. The Source engine has pretty good mapping tools, and there's a lot more that you can do with it, but there's not so much of a community there. Hardly anyone is playing Source games anymore, or at least not the ones I care about. The Source game I used to make the most maps for, called Hidden, might now have about a dozen total active players on a good day. (Which is a terrible shame, since it's still probably the most fun I've had with a multiplayer shooter game, ever.) Don't misunderstand my remarks about 3D portals, or 3D geometry in general. It's a very nice option to have, but the overwhelming majority of my mapping to date has in fact been for Boom-compatible ports. (Meaning no stacked sectors.) The thing that gets to me, the thing that has held me back from publishing any new maps in the last few years, is that everything I make looks just like something else that I already made before. I'm not sure how I'd even count the number of Doom maps I've made by now, but it's certainly in the dozens, and could very well be more than a hundred. There is nothing I can do that I haven't done before. That is, unless and until I can use light and shadows. Stacked sectors on their own are not enough. But even the exact same level can have a very, very different play experience depending on how it's lit. I don't like Quake. I don't like Unity. I like Doom. It's not about carburetors, or ECUs, or whatever. I want to feel like there's still some blank canvas left for me to fill in, again, instead of struggling to find novel ways to retrace the same old lines I've drawn a dozen times before, in one my my favorite video games of all time.
|
|
|
Post by ketmar on Jul 20, 2022 6:23:06 GMT -5
meapineapple, dammit! posts like yours is what gives me the energy and desire to keep improving k8vavoom. thank you!
|
|
|
Post by camper on Jul 20, 2022 14:01:54 GMT -5
Let me add the Torque3D engine (https://torque3d.org/torque3d/). The history of which goes back to Starsiege: Tribes. If you do something with open spaces, then this is a good tool. For example, look at the game Uebergame (https://duion.com/games/uebergame/main).
|
|
|
Post by 3t0 on Jul 22, 2022 21:01:32 GMT -5
I have actual gamedev experience. I am employed as a software developer, in another field. I'm not quite as refined in age as you and ketmar, but I'm not as far behind as you might think. I had a hunch, that I am preaching to the choir, but I usually don't listen to my hunches, to my own detriment. Heh. First sorry, if I came off as patronizing ass, but that is a way how I often come off. Do make much of it. It is a result from mix of my job (I do technical work, but also teach a lot of people, my underlings, and they fluctuate quite a lot and are often quite a lot younger), my personality (I am quite stubborn cynical jerk (with heart of gold ), my 1st language and most importantly specific style of speech I employ (I tend to often drop into pathos) - which when translated into English sounds quite condescending, at least I am told. One american guy once wrote about me that "I am trying to make him look like complete idiot in the most roundabout way possible" - I professed I was just being me. I used to try to be nicer, but then, often lot of info I wanted to pass around got lost, or more importantly, emphasis I wanted to point out, got lost, so I said to myself that I don't give a fuck anymore. Some say it's sign of my immaturity, I say it's sign of my maturity . At some point I simply accepted it's my style of going about things, and I am too old, "nasty", and most importantly, unwilling to change. So I just hope you are okay from my expositionary info-dump and are not such a fragile flower to get offended easily by my opinions. In fact you seem like pretty standard human being - which among infinite streams of snowflake sissies I see appearing on a event horizon is incredible achievement in itself. So once again sorry, if you chuckled somewhere along the lines. Second thing: I also used to do some gamedev work, "AAA" even, although the project kinda imploded. If you are willing to listen some of my battle-scars, I am happy to share any time. I've mapped and modded for a lot more games than just Doom. But I still have kept coming back to it. See, Prodeus has just about the most enjoyable 3D mapping tools I've used for any game so far, but (in my opinion) its gameplay kind of sucks... I can only imagine editing for Prodeus is top notch, naturally: it's Unity - hundredths (if not even thousands) of people work on it each day everyday, so that it slides into hipster ass like well oiled cucumber. I don't like Quake. I don't like Unity. I like Doom. It's not about carburetors, or ECUs, or whatever. Well then you must be ready to step down to lower "sophistication" level - which you seem to be ready to/already doing - Doom tools, even Ultimate Doom Builder are crude toys compared to polished turds of Unreals and Unities.
|
|
|
Post by 3t0 on Jul 22, 2022 21:03:10 GMT -5
zsh:[ ~p/gdev.doom-engines/k8vavoom/k8vavoom.git ] : ag Sector_SetPlaneReflection specs/3dpobj/zacc_acs/zspecial.acs 158: 159:Sector_SetPlaneReflection(3), // GZDoom only!
basev/common/line_specials.txt 143:159 Sector_SetPlaneReflection : UNIMPLEMENTED
So k8v does not support this nifty feature? Would it be very very hard to add ketmar?
|
|
|
Post by meapineapple on Jul 23, 2022 10:45:40 GMT -5
3t0 It's alright, you didn't offend me. But credit where it's due, Prodeus isn't just borrowing an editor from Unity. The editor is its own thing, specially made for that game. Clearly a huge amount of work went into that editor and making it so usable. ketmar I've still been messing around a bit with k8vavoom, and I've run into something peculiar. I can't tell if it's an engine bug or if I'm just doing something wrong. Do you know why this might be happening, and if there's something I can do to fix it? Here's the scene in k8vavoom: Here's the same scene in GZDoom: Here it is in Doom Builder: And here's the actual WAD (using both OTEX and D3 Retro resources): files.pineapplemachine.com/public/temporary/d4v22.2022.07.23.wadThe problem is that sector lighting values seem to not be applied to the tops of 3D floors. (The bottoms and sides seem to be lit correctly.) All these sectors, including 3D floor control sectors, have the same 160 light setting, but the tops of the 3D floor appear to be fullbright, for no reason that I've been able to sort out.
Edit: Oh, I think I've narrowed it down to only happening when there's an animated flat underneath the 3D floor. Seems like a bug?
|
|
|
Post by meapineapple on Jul 23, 2022 12:54:56 GMT -5
I found another sector lighting oddity. Scene in k8vavoom: Same scene in GZDoom: In this case, there's no animated flats involved. In GZDoom, the sector light value applies for above a 3D floor in a tagged sector, and the control sector's light value applies underneath the 3D floor. (Down to the bottom of the tagged sector, or to the next lower 3D floor, whichever comes first.) This is important, since otherwise sector lighting can't be used to create an effect of 3D floors casting shadows. In k8vavoom, it seems that the tagged sector's lighting is used both above and beneath a 3D floor.
|
|
|
Post by 3t0 on Jul 23, 2022 13:30:33 GMT -5
3t0 It's alright, you didn't offend me. But credit where it's due, Prodeus isn't just borrowing an editor from Unity. The editor is its own thing, specially made for that game. Clearly a huge amount of work went into that editor and making it so usable. I assumed, it has it's own editor, but you have understand point I wanted to make - that main workhorse is still Unity here - i.e. even if Prodeus editor is written from scratch it is written on top of whatever extension lanuguage (I think in Unity it's c#) they are using. Given style of modern development, I bet this editor acts as only 20-30% shell (percentage pulled out of my ass) on top of generic Unity APIs. Remember Microsoft's Balmer "Developers, developers, developers..." dance. MS always considered it's WIN API a crown jewel of Windows and more or less it's true. Case in point how this works: Qt toolkit (maybe you know it), Unreal or Unity always have commercial downstream consumers. These people pay good money to have support for the technology, but with that money they also buy a bargain/request chip from companies manufacturing those wares. So one day comes a guy and says: "I need to have this API which will tell me whether line is perpendicular to a plane". More guys come and ask for same API. Commercial upstream is not stupid - it catalogues and analyzes requests, and as such, eventually, if they see request popping up often, they will create that API. If it's "hard" API to provide, they will even implement mini-system to make it happen - especially if the API is considered extra worthwhile by the clients. This is what armies of unnamed programmer mules employed by these companies work on. More over these provider companies have legal and commercial obligation for these APIs to work an work well. So it has certain quality of implementation and integration. Compare that to shit like GTK and some other (what I call "pretending") linux tech if you have knowledge or chance. If you don't know what I am talking about, here is a small side story: there is lot of tech stacks on linux which don't have such stellar support like Qt, Unity on Unreal - there are no big commercial customers - it's fine for random geeks to built upon, but it would never work well for high quality commercial product, with deadlines and shit. GTK - graphics toolkit behind GIMP graphical program is one of piece of such ware. GTK is main contender (at least considered by some, lol) against Qt (which is GUI toolkit as well) and it came into existence when some guys wanted to write first graphic program (ie photoshop for linux) - they discovered they have no GUI to use, so they side tracked and wrote GTK GUI technology so they could write GIMP. Some years, until linux was taken seriously, that was only way to have graphical programs for linux plebs. yhese programs had to use GTK - GTK actually means Gimp ToolKit. The ware is atrocious, it barely works and holds together buggy as fuck flaky piece of shit. At some point company making Qt entered the linux sphere, and suddenly you got really high quality GUI system for linux. Maybe you heard GIMP used to be only painting program for linux - it's developers are stubborn same way as GTK developers are, there big overlap between them. They stood by their words and choices and thanks to that now by 2020+ GIMP is completely irrelevant: Qt ware overtook it. Most linux artists I researched use Krita, or anything else, but GIMP. Many of these painting programs are made with Qt nowadays. Why is it important: you can program silly media player with 4 buttons in anything, even by hand, and thus even in GTK. But if you want to program linux powered industrial level ship hull design application you chose Qt, same if you want to program GUI for refinery control plant. If yuo try to do that with GTK, you are in for dire surprises. These specialty apps need substrate which is performant, but also allows great customization for very special custom controls and has to be rock solid. As a programmer, I can imagine, you already see complexity needed for such tech-stack subsystems, breadth of APIs that needs to be supplied, robustness to not blow up because of weird integration decisions and such, etc. GTK "pretends" to be such ware but it is not. There are industry stories of some linux software stuck in limbo on GTK for literally decades, then suddenly being rewritten into Qt in literally weeks and then warp jumping in development speed each year and achieving such things, that could not have been achieved with GTK ever. So when we turn back to game engines, which is our specific point of study here - Unreal and Unity are Qt of gaming. The feature list is infinite, APIs are deep and wast and almost any query you can think of you can ask and any property you can read you can also set, usually completely dynamically. Writing anything in these systems is just mashing APIs together to get behaviour you want. Yeah I can imagine you can have working Prodeus editor pretty quickly. Now compare k8v: last time I inquired, it did not have yet .SetSlope() VavoomC API for sector (not that I want it ketmar). Neither it does have .GetWallNormal() or something else. And so on. So in many aspects internal abstraction level is below Unity, Unreal, neither it is "pretend" ware GTK way. There is nothing. Manipulation of internal game system structures is direct, not wrapped in. Then some Unreal spoiled kid comes and bawls: "bwaaah gzdoom is unoptimized", "bwaaah k8v cannot do this, cannot do that". "Yes, you cannot do that.", "Bwud bwud wdubb Unreal can, smirk...". Really? Then patches welcome, or fuck off to Unreal kid. Some younger doom people are literally comparing hyper polished product of evil multi-billion corporations during whose production thousands of people bled souls implementing shit for millions of manhours with 30 old tech polished beyond comprehension by guys in their bedrooms over sleepless nights, some from literally war-torn countries. Give me a break people. I know you are not like that meapineapple, I just wanted you to understand deeper "reasons". Yes ,you can slap PBR renderer on top of raw doom planes, or add anything else - even streaming terrain subengine if you wish for. But basic metrics are of essence: time, food and sleep. And if that is sorted out somehow, where do you get money to live, still? And what about your free time? Finally you do it, then how do you make it, so that plebs can edit it? I don't want to imagine how "nastily"/"cleverly" PBR is shoehorned into GZDoom pipeline. Now the game has PBR gets some social media glory, and suddenly there is influx of bawlers.
|
|
|
Post by meapineapple on Jul 23, 2022 14:17:17 GMT -5
I don't want to imagine how "nastily"/"cleverly" PBR is shoehorned into GZDoom pipeline. It's hardly at the top of my feature wishlist but, I mean, PBR in Doom is kind of cool. Writing anything in these systems is just mashing APIs together to get behaviour you want. Yeah I can imagine you can have working Prodeus editor pretty quickly. I'm not sure about that. I don't have all that much experience with Unity, but I do have enough to doubt this claim. I think you shouldn't undersell the Prodeus editor, not unless you have specific insight into it that I don't. It's doing things differently from any other map editor I've used, and I've used a few. Sure, it's going to benefit from the features of the underlying engine, but that doesn't just immediately launch you from a blank slate to an eminently usable 3D modeling tool. Have you actually seen or used the Prodeus editor? Otherwise I would be happier not to denigrate what appears clearly to me to have taken a whole lot of work on the part of a couple of guys who may very well have been working out of their bedrooms. (Even if I will point out that I think they missed the mark on the actual gameplay...) Then some Unreal spoiled kid comes and bawls: "bwaaah gzdoom is unoptimized", "bwaaah k8v cannot do this, cannot do that". "Yes, you cannot do that.", "Bwud bwud wdubb Unreal can, smirk...". Really? Then patches welcome, or fuck off to Unreal kid. I think this is partly a problem of documentation. I'm hardly a graphics programmer, but there are certainly ways that I could usefully contribute to k8vavoom, if only I knew my way around it. Engines like Unity and Unreal have heaps and heaps of documentation explaining how to interact with them. Doom ports, k8vavoom included, tend to have very little. So, yes, there will always be entitled people demanding that someone else do the work for them. But even fairly competent people like me, who often contribute to open source projects, can hit a wall if "patches welcome" is not accompanied by "and here's the documentation". When I encounter bugs in the open source software I use, more often than not I fix them myself. My code is in projects ranging from eslint to openmw. But k8vavoom doesn't even have build instructions, that I could find! That makes it very difficult to even think about contributing, about e.g. investigating those sector lighting bugs my own self instead of just complaining about them on a forum. I get it, I get that demanding documentation isn't any better than demanding features, it still takes work. That's not my intention. I'm just trying to point out why the situation here might not be ideal.
|
|
|
Post by 3t0 on Jul 23, 2022 14:59:02 GMT -5
In this case, there's no animated flats involved. In GZDoom, the sector light value applies for above a 3D floor in a tagged sector, and the control sector's light value applies underneath the 3D floor. (Down to the bottom of the tagged sector, or to the next lower 3D floor, whichever comes first.) This is important, since otherwise sector lighting can't be used to create an effect of 3D floors casting shadows. In k8vavoom, it seems that the tagged sector's lighting is used both above and beneath a 3D floor. Yes, if I am not mistaken and I remember properly, I think current behavior "might be correct". The problem stems from several reasons: 3D floors were considered killer feature of doom, there are multiple conflicting implementations and GZDoom is not first implementer(!). GZDoom is most popular implementer, though. There are basically three/four main lineages: - DosDOOM/EDGE 3D floor - I think EDGE/Legacy were first
- Legacy 3D floor - This should match DosDOOM/EDGE doomlegacy.sourceforge.net/docs/3dfloors.html
- Vavoom 3D floor - I think there is some reverse going on here: 3D-floor-sector floor is actual 3D-plats over-floor, and 3D-floor-sector ceiling is 3D-plats under-ceiling (?) and thus floor needs to be higher than ceiling - which is invalid in other ports
- GZDoom 3D floor - what you have in gzdoom
Now I don't know what you use - I assume UDB - not sure if it supports vavoom style floors (have yet not tried). So first I would try to do a vavoom floor and see how that behaves. If it disappears from editor 3Dview I guess it cannot do that. Then, I know vavoom/k8v parses map and translates GZDoom style 3D-floors into it's proper internal representation, maybe there is a bug in the translation?
|
|
|
Post by ketmar on Jul 23, 2022 15:24:56 GMT -5
zsh:[ ~p/gdev.doom-engines/k8vavoom/k8vavoom.git ] : ag Sector_SetPlaneReflection specs/3dpobj/zacc_acs/zspecial.acs 158: 159:Sector_SetPlaneReflection(3), // GZDoom only!
basev/common/line_specials.txt 143:159 Sector_SetPlaneReflection : UNIMPLEMENTED
So k8v does not support this nifty feature? Would it be very very hard to add ketmar? the whole mirror/reflection code is very broken for now. when i started to add features to renderer, i completely missed that part of the code, and it doesn't work right now. that's why reflections are turned off by default, and i never bothered to implement line specials for them: there is no reason to do it until i fix the renderer. sure, i'll do that sooner or later, but for now i don't fully understand what Janis did there. as i don't consider reflections as Very Important Thing, it's somewhere in the middle of my TODO list. Do you know why this might be happening, and if there's something I can do to fix it? totally not your fault. ;-) it's a well-known (for me ;-) k8vavoom bug with 3d floor lighting levels; i've seen it here and there on other maps too. the problem is that i still cannot understand WTF is going on there: it shouldn't work that way, but it does. i'll take a look at your example map and try to find out what is wrong (again ;-). the problem is that the description in ZDoom wiki is… not very clear. it may look clear for a mapper, but it's way more foggy for an implementor. and of course, it can be a simple bug in my code i missed (which is the most probable thing ;-). tl;dr: my bug. will try to fix is ASAP.
|
|
|
Post by ketmar on Jul 23, 2022 15:38:32 GMT -5
Neither it does have .GetWallNormal() or something else. 'cmon, you don't even need it, because each linedef already has precalculated direction and normal vectors for you!
|
|
|
Post by ketmar on Jul 23, 2022 15:53:33 GMT -5
But k8vavoom doesn't even have build instructions, that I could find! my fault. yet it is using bog-standard cmake, so there shouldn't be any problems… well, except if you are on windows. it may be surprising, but windows is actually not supported by k8vavoom. windows builds are done by MXE cross-compiler, but i myself don't have windows os. That makes it very difficult to even think about contributing, about e.g. investigating those sector lighting bugs my own self instead of just complaining about them on a forum. yeah, that's the big problem. while Vavoom/k8vavoom code is quite good, and… modularized? is it even a word? the engine is still very fragile. sneeze in a wrong place, and it will collapse. it took me literally years to start making sense of the code, and yet there are sill some parts where i don't understand a thing. i still have plans to properly document it, but… it really may take years of hard work. i mean, it's often harder to describe something with normal English than with the code. so i'm pushing that task further and further away (and thus cutting out potential contributors). i don't have a good solution for this problem yet. T_T
|
|
|
Post by camper on Jul 23, 2022 16:24:00 GMT -5
3D floors were considered killer feature of doom, there are multiple conflicting implementations and GZDoom is not first implementer(!). GZDoom is most popular implementer, though. You write very exciting. What can you say about 3d lines? They are used in risen3D: md2.sitters-electronics.nl/tut_lines.htmI already asked Ketmar, but I want to hear your opinion.
|
|
|
Post by meapineapple on Jul 23, 2022 16:27:41 GMT -5
Cool, thank you for the response. I am interested in making the most I can out of k8vavoom, but 3D floors are nice to have, and I feel that sector lighting behaving in a standard way is a pretty important part of that feature. For documentation, I don't think any potential contributor expects to have everything documented in exacting detail. But build instructions are a very good start, even just to compile and cross-compile on Linux, and after that perhaps a sort of directory listing the important folders and files with brief summaries of what the purpose is for each one would be the most immediately useful thing. The hardest thing when trying to make sense of a new codebase is generally the very start, just learning how to navigate it and how to carry out the most basic operations. For example, how would someone be sure that it was bog-standard cmake without combing through all your build-related files to see what's going on, or else YOLO'ing it and hoping for the best (which is not always wise), unless you said so? How else would anyone know that the Windows build is normally generated on Linux? This is exactly the sort of stuff that would be very very helpful to have in a clearly labeled text file. Documentation isn't an all-or-nothing thing! It doesn't have to be a mammoth years-long task. Every little bit helps to lower the barrier for potential new contributors.
|
|