News | Forum | People | FAQ | Links | Search | Register | Log in
Quake 2018: How Maps And Engines Are Better Than Ever.
Considering the following:

1. We're getting more map releases than we've been getting in nearly 20 years, and they're all of decent quality at the very least, and superb (that which are rivaling the undisputable classics in quality) at most.

And...

2. In 2008, for every 5 demos for a map:
- 2 would be Fitz 0.85,
- 1 would be aguirRe's AGLquake,
- 1 would be DarkPlaces,
- 1 would be JoeQuake or some other QW engine (???).

Each and all of those with their own protocols and idiosyncracies.

These days almost everybody uses Quakespasm - an actively maintained and cross-platform engine - as a standard.

Conclusion:

After a slump in the early 2010's, Quake is finally doing better than ever, with the player and mapper base growing and the game itself slowly creeping back into mainstream attention.

Discuss... or not!!
TL, DR: Too Busy Mapping / Playing Maps To Discuss. 
 
YES! 
The entire community coalescing around a single engine is ultimately a good thing; there's still room for the maverick outliers, but so long as you do-what-Quakespasm-does you'll get support for pretty much anything released.

The obvious con is that the quirks and idiosyncracies of that single engine become enshrined as part of a standard. That can cause harm - e.g. FitzQuake and earlier versions of Quakespasm had very poor performance with dynamic lights. That can hold back content authors from using dynamic lights, and at one point led to the ridiculous situation where disabling multitexture was touted as a performance tweak.

Fortunately Quakespasm these days is really rather good. 
 
Regardless of the largely unfounded criticism for Arcane, it has done a lot to reignite interest in this game, arguably alongside some other big releases like Orl's Ter Shib and jam9. On the mapping side, Trenchbroom 2 and dumptruck's tutorials have done wonders in terms of drawing in new mappers. They even got community veterans to finally map after 20 years.

I don't know if the scene is better than ever because I don't know what it was like before. It still seems quite niche to me but it's also doing considerably better than most other classics out there. The number of mappers who turn everything that they touch to gold is still quite small. I'm worried that when they retire, there won't be many people to carry the torch. Many of them already seldom post here or elsewhere.

On the other hand, this has resulted in mappers whom I greatly admire being more accessible. I've gotten tons of advice and insights directly from mappers whom I aspire to match in skill even if only in the smallest capacity.

Targeting a single engine is not a good thing. There are still a bunch of source ports that are actively maintained, and the devs each have different goals. Some of those goals might align with more with specific users. Even if most people are using Quakespasm, there are still a great many who might prefer using Mark V, QSS, Qrack, FTE, and others. There should be some effort made towards supporting multiple ports to a reasonable extent, and there are more reasons in addition to users simply preferring the features of one port over another. 
Bump For Baker. 
 
No Software Love 
 
Maps And Engines 
AND TOOLS! 
Things I'll Never Post.., 
A teleporter, who shows me how he played with a blurry screen in the earthquake in the nineties, threw me into the limelight with quadro-sound grenades and missed voreballs.

Uhm, my old 486 still does it, but I mean the surprise that such a comic strip film can mesmerize me like that.
What else would I like to improve? 
Watchu Talkin Bout Willis? 
hey guys, been away for a while, not 20 years but a while.

never heard of Quakespasm, what's it do better than the other engines? and who is the whole community that's now using it? can you name some names?

qmaster mentioned tools, what tools are you guys using?

darkplaces and fte are my preferred engines, but fitz is still good for the classic look.

tenebrae was all set to be a great engine, I don't know why they quit developing that one or nobody picked up its source to continue it. 
Quakespasm 
Is practically Fitz v1.5. 
Tools Are Better Than Ever, Particularly MAPPING! 
Tools::
==================
Mapping:
Trenchbroom level editor(fantastic)
JACK level editor (upgraded Worldcraft clone)
ericw's utils for compiking maps with cool lighting, {fence texture transparent support, water alpha, bsp2 oversized, the works

Code (QC):
fteqccgui.exe latest version with lots of great features, arrays, better checks for warnings, support for GIANT progs.dat, csqc support, etc.

Modeling:
Blender 3D with qmdl exporter
Preach's qmdl java applet for adding skins, Skingroups, framegroups, etc.

Textures:
Oh sorry, still stuck with Wally and Adquedit here.
Texmex is alright depending who you ask.
Gimp 2.10 if you like going back and forth a lot into Wally or Texmex and like to fight pallet conversions.

Sprites:
Fimg
Wally plus Adquedit

Lumps (e.g. colormaps, hud icons in gfx.wad):
Fimg
Adquedit 
#8 
Quakespasm is a continuation of Fitz that's been heavily adopted by the SP mapping community. Namely on this website but also Quaddicted, which has promoted it as their recommended engine over the past seven years. It has some new features, but it's primarily a faster, cleaner, cross-platfrom version of Fitz/GLQuake with increased limits.

Quakespasm-Spiked is awesome if you want an updated version of Fitz with enhanced networking, modding and mapping capabilities. 
Engines 
Quakespasm = bog standards plus fence texture support, alpha on any entity, bsp2 map size support, fog, skyboxes, colored lighting.

QuakespasmSpiked (QSS) = Quakespasm plus awesome features Spike added plus support for high framerates above 72fps, e.g. for 144hz monitors.

MarkV = same as Quakespasm for the most part but with better HUD options, cool map and mod loading features, excellent coop support, mirrors

FTE = you know better than I. As far as I know it is DarkPlaces plus the stuff Quakespasm has and a few extra awesome things Spike came up with that I don't understand yet :P

DarkPlaces = cool graphics options. TERRIBLE WATER!! Buggy physics outside of standard hulls. Loads of mod features. 
Rule Of Thumb 
If you want anyone to play your map, target Quakespasm, otherwise GLWT. 
I Prefere MarkV Over QS 
the main reason is frogbot support, not sure why , but sometimes QS refuses to properly launch that mod

i like the MV fancy features, tool_ etc, qmb

the FOV adjusting feature 
2018 Are Better Then Ever 
cannot recall any significant release this year, other than sham1m1 
Concerns 
a concern of mine is that with quakespasm it means you have to use the BSP2 map format, and not FBSP or a Q3 or even newer format which has more features.

FBSP has higher res lightmaps and lightstyles support, maybe some other differences that i can't remember.

from mh:
The objective of BSP2 is to address some limits in the stock BSP29 format. -- BSP2 is not a radical revision of the format. You won't find RGB lightmaps, detail brushes, 32-bit textures
or any such major overhaul here. These are left for other already standardised ways of providing such
content.

i'm interested to know if detail hint and skip brushes can indeed be used for BSP2. also how to create these RGB lightmaps? i thought colored light was only done with rtlights. can q3 style bezier patchmesh be used? can high-res lightmaps be created for BSP2 which are as big as FBSP? are we talking 2k maps or 4k or ?

another benefit to FTE (and i believe also dp) is it supports IQM/IQE model format, i can't find any document saying if quakespasm supports it or not. 
 
Some excerpts from EricW Tools doc:


QBSP:

This version of qbsp supports detail brushes which are similar in concept to Quake 2’s detail brushes. They don’t seal the map (previous versions did).

...

SKIP
Any surfaces assigned a texture name of skip will be compiled into the bsp as invisible surfaces. Solid surfaces will still be solid (e.g. the play can’t walk or shoot through them) but they will not be drawn. Water, slime and lava surfaces can be made invisible using the texture names *waterskip, *slimeskip and *lavaskip respectively.

HINT
Hint surfaces cause a bsp split and portal to be generated the on the surface plane, after which they are removed from the final bsp - they are neither visible, nor structural. Strategic placement of hint surfaces can be used by a map author to optimise the PVS calculations so as to limit overdraw by the engine (see also: vis(1)).

Use a texture with the name hintskip on any surfaces of a hint brush which you don’t want to generate bsp splits or portals. All surfaces of a hint brush must use either the hint or hintskip texture name.


LIGHT:

"_color" "r g b"

Specify red(r), green(g) and blue(b) components for the colour of the light. RGB component values are between 0 and 255 (between 0 and 1 is also accepted). Default is white light ("255 255 255").


All of which are compatible with Quakespasm. 
Re: Concerns 
Eh well, some of those things are possible with various engines, some aren't, some have been tried and don't look great in Quake-like content. I won't try to enumerate the details (muk has tackled some of that, and maybe someone else will also jump in), but a couple of general things I'll throw out into the thread:

For developers, if you're going to make a new game in 2018, a Quake1-based engine is unlikely to be the best choice.

For players who are specifically interested in playing Quake and Quake-like content, new features are not always needed. I'm not suggesting "no new features" is the right answer, but from a player's perspective it's not necessarily an issue when a Quake engine doesn't have a particular bolt-ons buzzword. 
 
the q1 standard for RGB lightmaps is .lit files, which most modern light tools can produce. These files can be used in conjunction with normal quake BSP files and also BSP2 files. 
Echos 
the only stuff in your list that you *can't* do with bsp2, ericw tools, and quakespasm - is q3 bezier patches (which isn't really a big deal).

Higher res lightmaps we're trialed (.lit2) but I don't know if that's supported in the main quakespasm build, someone else has to answer that one. 
Oh 
and it doesn't support a fancy model format yet. 
Ultimately 
It's up to the mappers to decide whether they want to use the new features made possible in DP and FTE. In this community (i.e. the mappers based mainly in this forum) they tend not to. If the content is there, more widespread engine support will follow. The content isn't there though. 
And Another Bloody Post... 
...I think the main reason mappers don't want to target FTE/DP is because the players (who are basically also the mappers), don't want to play quake under FTE/DP for various pretty understandable reasons (don't like the physics, don't like all the aesthetic stuff it changes etc. etc.) 
Models 
thanks everyone for all the info. this doesn't look as restrictive as i first thought. i would not do a whole game, more like a little partial conversion.

so if you were to create a terrain made of mesh, is the collision handled well? is it computed via the vertices of a separate collision mesh?

how good would the light look on it? this is a main reason why large lightmaps are useful to me. since large models need more lightmap.

i'm also interested about animation support of the models for making animated map models or making new monsters.

are any of the engines going to support realtime radiosity / raytracing? graphic cards this year are going to bring this feature, and it will become the standard going forward in games i think. 
 
Quake creates one lightmap per face (atlassed into fewer, larger textures at map load), so a large terrain made of many faces does not need large lightmaps -- it will just use many small ones.

In terms of how good it will look, there have in the past been bugs with visible lightmap seams at the edges between too faces, especially with odd angles. Not sure if those are solved with modern versions of the tools. But when the system works, you will not see the seams. 
 
that sounds right for brush-models, but what about static mesh models such as ase, md3, md6 or whatever models quakespasm is using? pretty sure it only uses one lightmap per polygroup or per shader or something along those lines 
 
models are lit using the value on the lightmap below its origin, or something to that effect. so a large piece of terrain as a mdl would look odd.

you could export it to obj then use a tool maintained by khreathor called obj2map.

bal has used it with success in his xmasjam2017 map. theres also an instance of it in otps jam9 map.

obj2map + phong can create some really nice looking terrain. 
 
Quake engines these days are very much focused on the look and feel of the original game but with as much quality/fidelity as possible. Replacement content, etc is of considerably lower importance than the original look and feel being as high quality as possible. If you want replacement content then this site is not going to be so helpful. "Pimp my Quake" doesn't really live here. 
 
Lightmapped terrain can mostly be done using _phong in ericw's light tool when compiling the map. That should smooth it out for you. Also the _dirt setting can add something similar to SSAO baked into the lightmap. 
 
i think you are describing vertex lit models muk? lightmap should behave differently. you can usually specify the lighting type in the shader it uses.

also if i recall, there might be a key like _origin which allows you to light the model in one place and let it spawn in another?

yeah i know there are quake-purists don't want to change the look of anything, but the water was never meant to be transparent, no colored lights were meant to be had here, and etc. where do we draw that line? is it too much to ask for some quality lightmaps and models? if we aren't using original bsp file or texture wads why do we have to stay with original alias mdl models? how have i overstepped the line here mh? :) 
Echos 
No need to be sensitive about overstepping lines. mh is merely pointing out the preferences of many of the mappers here. There are plenty of exceptions. No one is stopping you from using features you want if they actually are supported. You just might be limiting your audience as engines like QS and Mark V are slow to adopt new features by circumstance or design.

In other words: you do you. 
Modern Stuff 
I'm not sure that looking at Quakespasm to develop a game project if you are interested in things like RayTracing, md6 models and using static meshes to construct the environment is the most 'sensible' route.

Quake is brush based, and Quakespasm is meant to reflect that. The .mdl format is actually quite atrocious, and making terrain with mdl meshes is not going to work. I think the idea behind QS is to be faithful to 1996 Quake.

Although I love all manner of crazy and ridiculous ideas involving Quake, it really sounds like an idea of this scale would be better suited for Unity, etc.

It would also stand a chance to actually generate consumer interest in that case too. 
As Someone... 
...who has been using Unity for the better part of a decade I would say try Unreal first, for the sake of your mental health. Unity is great for banging out shovelware minigame type stuff, but try to do a proper game with it, and all of its dumb limitations and performance issues will gnaw away at you until you are a desiccated husk, devoid of joy or life. 
 
Yeah, it's 1996 Quake with some additions inspired by Quakes 2 and 3, and others from elsewhere. As a general rule the goal is high fidelity rendering of the original content rather than replacement content.

Shortly after the Quake source released there certainly was a push towards adding eye-candy features, but as the years have gone by things have settled more towards a realisation that the original look was a classic and that cleaning it up and presenting it in a modern, accessible and high quality package is a better goal.

There is no "line" here; when it comes to features (and pheaturez) it's a matter of testing what the community has appetite for, and choosing those which have fewer barriers to implementation but maximum return on investment. Picking fights you can win, in other words. So, implementing BSP2 for example is a couple of hours work, it coexists peacefully with everything else, and even software engines can join the party.

There's an argument to be made that if most of what you want is features from another engine, maybe you would be better off just using that other engine to begin with. "I want MD3, bezier patches, Q3 lighting" - the Q3 engine is a great platform that already supports those, maybe you should use that instead? 
Echos The Infamous Quake P1mper! 
i agree, quake looks like crap with a bunch of randomly downloaded replacement content and badly implemented eyecandy like bumpmaps lensflares and fog everywhere. that's not what i wanted at all.

is there any reason though that quakespasm supporting iqm would be a bad thing? it was supported in rmq which you were part of mh.

i realize i can just use another engine. if everyone went to another engine though there wouldn't be quake anymore.

the reason we were given qc and engine source at all was to expand and go nuts. has been this way since the beginning. i think if we are artificially constraining ourselves to an idea of what quake was, that's not quake at all. we wouldn't have had qrally or tf or malice or all sorts of other things without innovating and using quake as a platform. quake-movies, now known as machinima for example.

quake the engine is not the same as quake the game. you can still do a classic looking map with access to extra engine features. switching all the features on like a spastic kid in a candy store isn't the answer. having it there as a feature for modders to make use of is the way.

ericw's light is using texture-based radiosity which originally came from hl, it doesn't mean these maps are all going to look like hl maps when compiled under it though obviously. we need more features like this, not less. 
 
You are basically just saying "why can't we make Quakespasm the same as Darkplaces and FTE".

The easily answer is of course "Just use Darkplaces and/or FTE". 
 
engine popularity comes and goes with time. right now it's quakespasm, and tomorrow who knows what it will be.

i don't really want to force people to use a particular engine. i want to know my sprites and models and maps will just work.

there used to be a quake standards group to make sure everyone was supporting common file formats and things like that. 
 
I think it's reasonable to say that absolutely nobody likes the MDL format. Not even John Carmack liked it back in 1996. What it's trickier to get consensus on is: what should replace it? There's solid arguments to be made in favour of a number of different options, of which IQM is only one. 
Question 
Considering the currently way-too-high barrier of access in modelling for Quake, how much would a wide implementation of IQM help eliminating it? 
#38 
I like either of these 2 options if we're talking about a better model format in the 'spasm:

1) A conservative update of .mdl that simply bumps up limits, most crucially making vertex coords 16-bit instead of 8-bit. The model equivalent of bsp2 basically. Because it's similar to vanilla mdl, it should involve the least amount of bollocksing around to get engines supporting it.

2) md3. This has the advantage of already being a standard. It lacks stuff like quake's model flags though, so there's other bollocks to consider. It has the advantage of existing tool support with blender scripts and whatnot. 
Then Again 
Already - Darkplaces, FTE and Quakespasm-Spiked support md3.

Number of quake mods from funcsters that use md3 models: 0

No content, so why should any other engines bother with the support? 
 
MDL sucks except for where it doesn't which is morph animation and the ability to make polygons dissapear in certain frames such as some of Preach's effects models or as completely different poses such as mushrooms or candle models from AD.

I don't know of any other format that let's you make each individual frame as if it were a separate model except for source engine's .MDL which is pretty much the same thing but you can have skeletal animation and use a separate mesh for collision.

All else uses a skeletal armature as far as I know. 
Ya Nope 
Still can't find anything other than blendshapes and even that is 't as powerful as the .mdl format. 
Qmaster 
md3 is a vertex animation format too. 
Model Formats 
mdl, md2/3/4/5/6, and iqm are all a quake specific model format. that's both good and bad, but mostly bad as far as the modeller and animators are concerned.

i think without question the best model format would be either FBX or collada, these are the most common formats and modelers and animators will be able to export for it easily from many different tools.

as far as removing the barrier to modelling of quake: this might get more serious modellers interested to make models for quake since they don't have to work with ridiculous formats they've never heard of. fbx and collada are so common the exporter is installed by default on most modelling packages. this lets a modeller make models for quake without knowing anything about quake at all. also lets you download these very common files from the net and use them directly for people who can't model things.

https://en.wikipedia.org/wiki/FBX
https://en.wikipedia.org/wiki/COLLADA

these files could be parsed with a standalone utility to add flag data or any other data into the file itself, because it should support arbitrary data within.

might be possible to add this data in the model editor itself by hand. like to a blind data field or on a non-rendering polygroup in the model.

collada is a non-binary text file so it would even be possible to edit that file by hand.

iqm is not too horrible though, i've tested it out. supports fairly high polygon counts and skeletal animations, as well as multiple shaders. also works good as non-animated static mesh.

collada and fbx file formats though are basically futureproof and support an unlimited number of triangles, and etc. whatever limits your engine decides to support will not need to be adjusted in the file spec at all, just the engine. you'll want to allocate as high a limit as possible. 100k triangle mesh is almost considered low poly in some circumstances today. consider the high-res monitor resolutions when quake was released, everyone was playing 320x240 and yet it supported really high modes to future proof it. 
 
both collada and fbx support blendshapes, if the game engine will support parsing that data and using it. you can have blendshapes and skeletal animation in the same file so it's ideal.

it perfectly replicates the vertex animated behavior of the .mdl alias triangle models.

when doing blendshapes the winding order of the vertices is important, so keep it in mind when creating your file parser. 
 
My vote is on md3 (if it matters) as a standard extra format to support. DP and FTE already have this I believe.

Relevant Exporters here for everything:
https://www.katsbits.com/tools/

FBX is not bad but it can be a lot harder to fully support it. Unless someone has the time it prolly won't happen. 
Qmaster 
the .mdl files originated as .tri files from alias power animator. they only become a .mdl when they are compiled by a model tool that came in the original quake sdk. this compiler was named modelgen and in q2 it's called qdata.

the direct decendant today of that file would be blendshapes stored as an FBX file, exported from autodesk maya. so blendshapes are indeed as powerful as the .mdl file, it's identical.

alias was sold to autodesk in the 90s. power animator became maya.

blendshapes are able to be created by almost any program, so maya is not needed.

saving blendshapes as FBX or collada does the exact same thing. either file format works fine. 
 
Theres been over 200 single player maps made for Quake in the last 2 years. I think Quakes doing just fine without all this stuff you're asking for that's already implemented in other engines no one wants to use. 
 
some implementations of these model formats are only partial. for example in spikes version of quakespasm he doesn't support shaders or tags on the md3 file. so you have to be careful here what you're asking for.

it would be great to have one solid implementation of a model format that can do it all and be used across all the quake engines.

converting a md3 into collada or fbx would be easy, you could batch convert them over with no user interaction required i bet. 
 
Theres been over 200 single player maps made for Quake in the last 2 years. I think Quakes doing just fine without all this stuff you're asking for that's already implemented in other engines no one wants to use.

Indeed. This is the stark reality. I'd like to think there's all these incredible maps and mods that are just sitting idle, waiting for Quakespasm to implement md3 before they unleash themselves into the world, but I think in reality if quake content creators actually want to use other model formats, we'd have seen some content by now. 
Give Tim Willits A Call... 
Seriously who are you going to retain to perform the labour behind developing a new Quake engine that will support fbx format, static mesh with collision, and 'ray tracing'. Do you have a 7 figure budget?

Honestly just call up id and ask to license idtech 6. This is absurd. 
Lol I Know Tim Actually, Great Guy 
kinn, i noticed that you were asking when qs would support q3 map format in another thread... in this thread you said nobody wants this newfangled crap!

the reality is people do want these things, including you, but every time it gets brought up on here there's a huge backlash against whoever asked for X new thing. quake doesn't need this shit blablalba. i think people have just given up mentioning stuff like this because it might get into a flame war for no reason. but this thread was created specifically to talk about it so here we are!

anyways, lots of great information in here so far, and in case anyone wants to consider it we have lots of ideas for improvements to make maps and engines better than ever.

@Redfield, i don't think its absurd, we already have mesh with collision or you would fall through the floor of the brushes you stand upon. none of what i mentioned requires a 7 figure budget. 
 
kinn, i noticed that you were asking when qs would support q3 map format in another thread... in this thread you said nobody wants this newfangled crap!

this weird obligation people have to pull up old opinions(3 years old in this case) of people to use against their new, current, opinion is pretty absurd. 
Echos == Otp Confirmed? 
I'm taking about the actual reality of how and why things get implemented.

Of course I think it would be cool to have md3, q3bsp etc etc. Doesn't mean I can't drop a few sodding truth bombs every now and then does it?

I'm not saying we shouldn't have these things, I'm saying this is why we don't have these things, and this is why the programmers don't think it's worth their time supporting these things. 
One More Thing. 
i keep hearing stuff like "if people wanted it we'd see X by now", here and in other threads.

i don't think it's that easy to dismiss. for example why didn't we see many q3 format maps?

because darkplaces didn't support the full implementation of the q3 shader system. this basically killed it for me and probably everyone else. and FTE uses and ungodly complex glsl shader, i would have to convert all my shaders over to that after learning glsl.

as well, model/anim implementations vary so wildly and are partial at that. if it won't support what you want to do because it's partial, it's as good as no support at all.

if you don't agree it's fine, but this is my take on things. 
And It's Pretty Dumb 
considering how obvious it is that otp just pm'd you (or whatever) with that incredibly controversial info.

Oh my god I once said q3bsp is cool.

Oh shit I still think q3bsp is cool what now. 
@kinn 
TREASON? 
It Gets Better 
spike called qs crippleware in the qss readme. that's a solid burn. what's the verdict on that?

i won't dig up any more quotes to throw at you guys for now, it's making you paranoid hahaha. 
 
Spike also released FTE with literally no documentation making any desire to design for it null from the start. 
 
The best model format is a binary format that you can fread into a VBO. Plain text is fine for intermediate formats, but for the final thing that you're going to use in-game, load times are pretty damn important.

Spike described NQ as crippleware. Not specifically QS, any kind of NQ. But Spike has a QuakeWorld background and judges things by different criteria. 
My 2¢ 
If you want to make a quake 3 map why not just, you know, map for Q3 instead of making a Q3 map then turning around and trying to run it on a Q1 engine hacked up to play Q3 maps? If the lack of quake 1 enemies is a problem just download a quake 1 enemies mod then base your map on that.

As for models I think FBX would be a great idea too although there should be an FBX > MDL converter made so people can convert their model for use in more vanilla-ish engines that don't/won't support more modern advanced formats. I would also be kind of concerned about performance concerns of really high poly meshes (at least really high poly in quake terms anyway)on lower spec pcs, the way I see it quake is a great game for lower end pcs and laptops- and why wouldn't it be considering it is over 20 years old at this point- and the mdl format helps with that because it gives strict well defined limits on what you can do and those limits also happen to help keep the models lightweight and able to help maps run better, my lower spec laptop already apparently can't run quakespasm without -noglsl which makes no sense since the gpu SHOULD support that, it isn't particularly happy at the thought of quake having compatibility with a model format with unlimited vertex/face count texture resolution etc, surprisingly enough. Potato lives matter you know ;~; You know there will always be that one guy that spams free high poly models that they downloaded from sites like Model Resource in their maps just like how in Doom mapping you have some people that just decide it would be a great idea to make their map in the most advanced format just so they can copy and paste a bunch of random custom shit in it from Realm 667/. Then they will post it for people to play and shockingly to no one, it runs like shit even if it's vised unless you have a super epic high spec system which like I said makes no freaking sense for a 20+ year old game but oh well that's just how it is.

I get that I'm obviously kind of biased in that regard but still I think that's something that should be taken into consideration. 
 
i'm really just speaking as a modeller, animator, and mapper here. i can code a bit and know a few technical details. for example i know vbo is a vertex buffer object.

my suggestion is you could have the engine parse the collada at first use and save it out in its own native format in the userdir, that's what many games are doing.

blendshape anims should be allowed to deform along with the skeletal for doing facial anims on characters.

this would give the ideal solution for endusers, if they want it or not is another question. how many people wanted this and got ran off by an angry mob years ago, or how many want it now and are afraid to say so? lol

it shouldn't matter who wants what, if the engine is going to support models and animations it should do it in a smart way. coding the engine features by taking votes from an angry mob isn't a good way to go in my opinion!

so says the black sheep of the quake commune, baaa! 
 
just out of curiosity, whats the last Q1SP youve played, echos? 
 
@muk: it was one from sock, i really like his mapping style.

@therektafire you made some good points, i won't cover all of those but i will say most of your concerns are because of newbie mappers over-using triangles. there's nothing you can do about it, just don't play their map.

vis won't help unless it can seperate the map into smaller pvs sets. if a pvs is using too many triangles then you will have a slideshow. a good mapper knows there is overdraw on top of that, and performance takes a hit when moving between pvs's since more is visible from that spot.

i have tested an iqm mesh with 50K tris in fte and it worked fine for me with no slowdown, and that's using a midrange older gen graphics card.

newer gen cards would allow higher res meshes or more of them to be used in the same area. 
Echos 
Good luck with your project. Sounds like you have it all figured out. 
 
thanks dumptruck, my project is more about the models and animations than anything. i wanted to put some monsters into quake which are more modern looking.

since everyone is going to attack me again saying i'm the only one who wants to do this... no. i'm not the only one.

see for yourself on youtube:
https://www.youtube.com/watch?v=X9Dtdq_wBBU
https://www.youtube.com/watch?v=8-x91pvL97A
https://www.youtube.com/watch?v=qi7iLEolsn8

it may be better for me to just take all my models and put them into another game entirely if everyone here really hates newer looking models. i would have no audience to appreciate them. at the moment a project like mine can only run on fte or dp engine, which you guys say nobody wants to use any longer, this is also a problem. for now i am just making my models, and i don't know where they will end up at. i'm only going to do 3 maps at the most to put these models into, maybe only 1 map.

i made a map a while ago but it relies upon lots of q3 patchmesh, if i could convert these patchmeshes into mdl models maybe it would be playable in qs as a bsp2 map. i can convert the brushes easily but not patches. i would probably have to write my own app to convert patch data into obj files and then convert those obj into mdl.

i'm only a hack at coding so the ai for my models would be utter shit, but since it's quake the ai was always shit so purists can rejoice lol. 
 
at the moment a project like mine can only run on fte or dp engine, which you guys say nobody wants to use any longer

People don't want to use FTE or DP to run content which already runs perfectly under QS.

If you make something that's targeted specifically at DP or FTE, then that's a completely different story and (shock, horror) you might actually have an audience.

Instead of this weird hostile attitude of somehow assuming no-one here wants to play your stuff before you've even made it...you could just try, you know, making something for DP and FTE? If it's good, people will play it. 
 
I don't think you're being attacked.

What's happening here is that there are - for the purpose of this discussion - two directions for the Quake engine.

One of these directions is a platform to create lots of varied and semi-generic content on.

The other is a platform to play Quake on.

So, this site and this particular part of the community has a preference for the second direction, which is why an engine like QS is the way that it is. New formats typically don't exist and when/if they are created, they are in response to very specific hard limits in the old formats.

That's why BSP2 exists but MDL2 doesn't. Stock BSP has limits of 65536 or 32767 in several of it's content lumps, mappers started hitting those limits, so a response was required. Stock MDL may look crap but there's nothing about it actually preventing people from doing stuff.

That this part of the community prefers the second direction doesn't invalidate the first. By all means use DarkPlaces, which is very much tooled towards the first. Few people in this part of the community use it, but it certainly is widely used elsewhere. 
 
I would say that people in this community would use DarkPlaces, if there was good DP-specific content to play.

There isn't really yet though.

This community is driven by good content. So far, that's almost exclusively been stuff that you can just run under QS.

I think there was that one time when Tronyn did a big release that only worked in FTE. Guess what? We all downloaded FTE and played it. Holy shit. Oh and also guess what - future versions of QS then added support for it. Mind blown.

Admittedly, that was more about limits being broken, rather than radical changes to file formats, but I'm using it to illustrate my point that this community is content-driven, and changes happen because we want our engines of choice to support good existing content (that might otherwise only work under less-popular engines). 
 
kinn: Instead of this weird hostile attitude of somehow assuming no-one here wants to play your stuff before you've even made it...you could just try, you know, making something for DP and FTE? If it's good, people will play it.

also kinn: If you want anyone to play your map, target Quakespasm, otherwise GLWT.

where did i get a hostile attitude and assumption? it was from what you told me when i first came here.

now you are blaming me for holding hostile assumptions but they are just the "facts" that you all gave to me. i only know what you told me, and i have been away from quake for years.

i'm not tronyn so if i release something i highly doubt anyone would be making a special case out of it to code support for my mod into all the engines. nobody here knows me. qs doesn't even support nehara though either, so... popular or even a retro style mod doesn't always mean supported. 
 
There's no contradiction really. Yes by having something that only runs on FTE and DP you are initially limiting your audience, but then you can mitigate this by having this thing you've made just for FTE / DP be really good and worth playing.

It's a pretty easy concept - if you make something average and unremarkable, that only runs in DP/FTE, then I doubt many people will bother to play it, because no-one can be bothered to go out of their way to play something completely unremarkable in an engine they almost never use.

If you make something totally awesome that only runs in DP/FTE, then you have a very good chance of finding an audience.

So again, good luck with that, and I mean that in a sincere way. 
 
If you make something totally awesome that only runs in DP/FTE, then you have a very good chance of finding an audience.

True. Also you said that you want to make a TC. If so, you just bundle FTE with your mod and done. 
 
a completely faithful re-creation of the original quake monsters would be possible with a new mdl2 format. or new monsters which fit a retro theme. higher res and smoothly animated, not a godawful eye-rape like you guys think i am going for lol.

i understand the desire for a retro look and i support it, that's my preference too. i don't think high-res is mutually exclusive to a retro look though.

as it stands, if i tried to re-do original monsters to look better but still identically the same as they ever did, i hit a hard limit. also as mentioned earlier you can't do things like a terrain with mdl very well. original quake did have some outdoor areas, i think it would be interesting to do some as mesh.

nobody really expects me to create and release monsters that don't work in any engine before limits are increased do they? i know for a fact some mapper didn't invent the bsp2 format himself, then make maps in it, then upload these and say hey here it is, please implement my new format in your engines. he would of also had to make the .lit file spec and the compilers and everything else himself too.

that's basically what you guys are telling me to do with my models here, there isn't really the ideal model format existing yet. iqm is good but not completely ideal since i don't think it supports vertex anims, just skeletal.

i don't expect anyone to code support for this for me specifically, but i'm just putting it out there to illustrate a problem for modellers and animators in general.

you could ask on polycount what they would want for more opinions from actual modellers and animators, since this is mostly just a mapping forum. 
 
Show me your portfolio, or at least examples of models you did in the past. 
 
@khreathor: that was my original plan, but i thought those were the engines everyone was already using. so it didn't make me feel too bad about forcing an engine choice on them.

quaddicted tells you qs is a recommended engine, but look at how bright that screenshot is... jeez. that's not how quake was suppose to look. i'm not taking their advice after seeing that! :)

https://www.quaddicted.com/quake/recommended_engines 
Folio 
i'm not here to show off, the peanut gallery will probably pick apart my stuff and say it's no good just to troll me at this point! i'm the black sheep quake p1mper now.

i have made a lot of modern looking counter-strikey stuff lately. my quakey stuff is much older and looks similar to id or zerstorer or beyondbelief. 
#74 
nobody really expects me to create and release monsters that don't work in any engine

So are you saying you're trying to do something that requires features that aren't even in FTE and/or Darkplaces? 
Posted #78 I Meant 
 
Kinn You Might Be Rright. 
But even if so, I don't think untraceable anons should be making the similarly toned accusations. At least if there is disagreement you can be identified to answer to. 
 
exactly why i didn't post my folio, thanks for proving me right dipshits. typical forum troll bs. 
And The Same Applies To You Echoes. 
 
 
Yeah, further discussion is counterproductive.
Just make your models for FTE with md3 or iqm.
Also Chillo already remade all Quake monsters, we have few shamblers and grunts from other artists too.

exactly why i didn't post my folio

Well if you have top notch portfolio, it will defend itself.
If you can't pull off better models than what we have (from Chillo etc.) then it's a waste of time imo. 
Kinn's Post Deleted At His Own Request. 
 
Woo, Late To The Party 
So quakespasm has had a slow gradual creep toward more detail, thankfully it's been handled fairly well so far.

My concern regarding adding x new model format to QS would be modellers bringing models that are way over-the-top in level of detail.

The concern is that this would make the pixel density of the map textures look stupid.

For maps to be consistent with the models, we would need to use high def textures and would need to start including environmental assets in our maps. It could quite easily get out of hand.

Some kind of poly-count restriction is still needed IMO. Alternatively a workflow / tools that can be leveraged better to bring modellers in. 
Quake Engines 
When I first came back to Quake around the time I released Q-Deck I was still using DirectQ. I loved that engine. I moved over to Fitz and Mark_V sometime after when I started getting errors loading my maps, I started seeing engine limitations.

Now I pretty much have transitioned to Quakespasm. It's feature set has matched many of the things I enjoyed in Mark_V (the weapon view model being large like winquake, engine speed, extra menu features etc)
QS has surpassed it though as it has added a cool low res pixel looking mode with r_scale, decent controller support and Mark_V seems to take about 30 seconds to boot up whereas QS is instant.

I'm still waiting on good splitscreen support though, that's definitely the holy grail for engines. I know FTE has it but that engine doesn't have the ease of use of MarkV OR QS. 
@echos 
Your fiend is top quality! That video just freaked me out!!

Ok, but honestly, there is no quake 1 engine that can handle or do it justice; I mean in a real in-game scenario. Multiple enemies, rockets, particles, physics etc...

Seriously, if iD Software wants to make a singleplayer campaign for QuakeChampions, they should def give you a call. Or better yet, call them.
It's not that your work isnt great, it's just that,
it doesnt fit quake1. Thats like trying to remake minecraft with 24bit textures and curved surfaces.

I hope you find someone to help you remake quake in the unreal engine or qchamp's (where it belongs) I'd love to see that fiend in a dark alleyway :) 
Edit: 
Well, that wasnt your model i assume. oh well. 
@R00k 
He got ip-banned from posting after getting lynched by the terrafusion crowd, so don't expect a response from him here.

You can find him on irc if you need him. 
If You Mean Echoes. 
He hasn't been ip-banned from here at all.

I edited two anon posts that were abusing him, edited Kinn's post on request as it was quite inflammatory, and also edited another abusive post from echoes under another name. This is just to 1. stop anon trolling, and 2. keep the discussion civilised.

I haven't been following the discussion itself. 
Okay Apparently Marking As Spam Blocks IP. 
So unmarking echoes inflammatory response under "FU" alias, so hopefully the ban is reversed?? 
 
Oh yeah, IPs are blocked if you flag spam unless the post is by a registered user. This is for the days when we only used it for true spam by spammers and not questionable posts from community people. I guess I need to separate that out at some point. In the short term you could register an account to get around it. 
 
And unflagging the post would clear the IP block , correct. 
Not Getting Banned If You Spam Shite. 
Sounds pretty reasonable to require someone to have an account for that little perk. Currently I don’t think there’s any advantage in having an account beyond looking more legit. 
... 
the 2 posting crap at me were clearly Kinn and/or khreathor, if you want to find out just check ip logs. was it an honest mistake i got banned? shambler was siding with kinn that i'm some kind of liar or don't know anything. why were the other posts edited and only mine was marked as spam? why not edit all posts, or mark all as spam? the one specific way that results in me banned and not the others was taken, and it took more effort to do it that way.

@rook, it's not my model but i like it too. i was just trying to show what's possible and that there are others like me who want to ruin quake by putting nice looking things in it. i have already put my models into fte, dp, and ue4, they look very similar in all three. ue4 is better in some ways, but it's mostly due to how much easier it is to make things for that engine. it's pretty much bare-metal here, coding GLSL shaders by hand for example instead of a node based shader editor w/ drag/drop UI. things could be better and there's lots of room for improvements. Shader editors, PBR materials, blendshapes, lots of things that would make life easier or improve the looks.

for the little babies who got mad at me for saying i didn't like that bright picture of quake: i think you're a llama if you play quake on fullbright mode with no shadows in it, we would consider that cheating back in the day.

it's right up there with wearing all-black skins to hide in the shadows so nobody sees you in MP. also it looks like crap with no shadows, the shadows are meant to be seen.

i prefer to expand limits to make quake better but if your idea is to reduce limits, i don't think you should do that at the engine level, why not just make a reduced limit mod and ask mappers to target it.

one of you suggested a poly-count restriction on the engine to prevent new things. great idea if you apply it to the mappers too and not just the modellers.

it would mean saying goodbye to things like "Arcane Dimensions" !!! 
Echoes 
Sorry for the confusion. I'll try to be clearer: There is currently no edit option for moderation, only "Mark as spam". I have used the terms interchangeably, but it's only one action - "Marking as spam" is the only censorship option we have.

In this event:

Two anon posts abusing you were marked as spam.
Kinn's post was marked as spam on his request.
Your anon (i.e. posting as a different unregistered name "FU") was marked as spam as it's too close to anon abuse.

I had completely forgotten that this also results in an ip ban which was not the intention at all. As per discord:

[10:00] onetruepurple: so by marking an echos post as spam, you did in fact IP ban him
[10:02] Shambler: does it?
[10:02] Shambler: oh
[10:02] Shambler: well
[10:02] Shambler: ffs
[10:02] Shambler: that needs fixed
[10:23] onetruepurple: ggwp not figuring it out after years


Hope that's clearer. The standard I'm trying to stick to is that anons do not get to post abusive / provocative / trolling message because they are not accountable and cannot be consistently answered to (unlike registered users, e.g. if you took offence to Kinn's post you can answer directly to Kinn). Unregistered users sticking with a consistent username have more leeway of course. 
 
players don't remember models or formats, they remember maps. 
 
the 2 posting crap at me were clearly Kinn and/or khreathor, if you want to find out just check ip logs.

Pls... I'm not a 13yo small dick troll, who has to hide behind anonymity to insult people... I can do that while being logged-in :D

one of you suggested a poly-count restriction on the engine to prevent new things. great idea if you apply it to the mappers too and not just the modellers.

Yeah but maps still keep retro look, they are just getting bigger (in most cases). Their "poly" density feels right for retro stuff.
It won't happen with models. You'll build 50k tris model, put 2k texture on it, but entity size in game will stay the same. It will look off imo, with weird pixel and polygon density. Same thing happens when you put 4k textures on a low poly level, it doesn't feel right.

i prefer to expand limits to make quake better

We can expand engines like FTE and keep QS lightweight for stuff more close to vanilla. I don't see any problems here, especially when FTE is good for TC mods.
Tbh best option would be porting Quake to Unreal4 and then you have all eye candy stuff and all modern tools available.

i think without question the best model format would be either FBX or collada

COLLADA is an intermediate XML format which gives big ASCII files and you have to parse it to get data, you can't just load it like a binary file.

FBX has binary format, but there is a problem with license when you are using it in open source projects. That's why Blender has some bastardized FBX importer/exporter which can't handle half of the features. 
Kreathor 
I think he's whole shtick was "Geez guys why isn't it possible yet to make something that looks like UE4 in a Quake source port? Pfffttt" - referring not only to characters, but environment as well. Realtime radiosity lighting, raytracing blah blah blah.

The answer of course, is the same answer every time this comes up, which is "Use an engine that's designed to do all that modern stuff, like UE4, but you'll probably have to wait for Unreal Engine 5 for the realtime raytracing stuff, I don't think 4 does that yet." 
@khreathor 
I suggested the poly count restriction. Something like md2 format. The idea being to gradually increase the quality level so that the models keep up with the other things that the engine is capable of, without being over the top of course. What other quality of life stuff could other model formats bring us?

So a more philosophical question then... Is it better to have the tools and limit yourself?, or is it better to have the tools limit you? Because I can see both arguments and I don't know if there is a right answer.

I made a thing because I'm curious.
https://www.strawpoll.me/16504178 
 
I support the notion of having the tools but the mapper limiting himself/herself.

Maybe the tools could have "soft" limits, though, meaning that they have the option of warning the user when some limits are exceeded but still having support for higher/unlimited limits.

That way users don't need to be stifled but still be informed when they're about to cross the line. 
What Kinn Said... 
The standard answer to "I'm making my own game and I want a custom Quake engine that has all of these features that $OTHER_ENGINE has" is: "why don't you just use $OTHER_ENGINE instead"? - It'll save yourself and others a lot of pain and suffering.

What's sometimes difficult to get people to understand is that the cost of a new feature is not just the time to initially implement it.

As well as coding it up, testing it, debugging it, integrating it, and (optionally) documenting it, you also need to maintain it and ensure that it co-exists peacefully with any other new features that might also be implemented in future.

This increases complexity on an exponential scale, and it's well-enough known that people can have difficulty fully appreciating how quickly exponential scales explode.

Take Nehahra as an example, because it's a good one. Few engines support Nehahra, and the reason why is that it's a pain to integrate with other engine features that have since become standard.

To be more specific take Nehahra fog. Nehahra uses a different fog algorithm to what is now standard, and while that's a simple-seeming case, what it actually means is that anything you do that touches or interacts with the fog code now has to be tested twice. And because virtually everything does that, a simple feature has effectively doubled part of your workload.

Now implement Q3A-style fog volumes and watch your workload triple, as well as being in a position where you have 3 different fog systems and you need to sort out how they interact with each other.

That's why when people say stuff like "Can I have features X, Y and Z, Source and Unreal have them" the appropriate answer is "well go use Source or Unreal then". 
4 posts not shown on this page because they were spam
Post A Reply:
Name:
Title:
Body:
message
question
exclamation
idea
flame
noflame
error
skull
beer
moon
pent
rocket
sheep
pacman
pig
cheese
worldcraft
gauntlet
crate
pitfall
pimp
smile
cool
sad
frown
oi
yay
tongue
evil
wink
neutral
q1
q2
q3
ut
hl
cs
doom
dkt
serious
cube
Website copyright © 2002-2018 John Fitzgibbons. All posts are copyright their respective authors.