News | Forum | People | FAQ | Links | Search | Register | Log in
Screenshots & Betas
This is the place to post screenshots of your upcoming masterpiece and get criticism, or just have people implore you to finish it. You should also use this thread to post beta versions of your maps.

Need a place to host your screenshots? Upload them here:
http://www.quaketastic.com/
Username: quaketastic
Password: ZigguratVertigoBlewTronynsSocksOff
File size limit is 128MB.
First | Previous | Next | Last
Respectfully Disagree 
People have had 15 years to say "I'm using MD3 and you just need to switch engines", but nobody does that. Nearly all the engine additions that have been actually adopted (skyboxes, fog, coloured lights) succeeded because they were backwards compatible.

It's not about being able to still play it in dosquake, it's about being able to play it in any engine. That's pretty important if you want to keep all the players who don't pay much attention to engine developments, or who value the stability of engines with slow release cycles. Writing off a percentage of an already small audience seems unwise.

Nobody's ever tried to make backwards compatible enhancement to the .mdl format, I'd like to see if it works. Maybe it won't catch on, but the nice part is that it won't matter - because any content that experiments with it will also be forwards-compatible with future engines if it turns out to be a dead end. 
Clarification 
I'd like to see if I can make it work 
 
I agree that the model that seems to succeed is where there is an acceptable fallback for engines that don't support that feature, such as entity alpha, skyboxes, fog, fence textures, lit files, external textures, etc. In all those cases the content is mostly still playable in a vanilla engine.

There are exceptions: aguirre's extended bsp limits, and the bsp2 format are two cases where there is no fallback and it still caught on and became accepted. I was going to add protocol 666 to this list, but this is not something forced on people by a map or mod, so users still have a choice of protocols that provide the raised limits. 
 
protocol 999 
Large Bsps 
I agree that extended BSP limits are the rare exception that tests the rule (and this is coming from someone who usually doesn't bother playing maps in bsp2 format). To my mind the key difference there is that it's about breaking limits more than visual enhancement, and there's no obvious way you can do that in a backwards-compatible way. 
Just To Complicate Things 
I always figured the reason to do a 16-bit mdl format is so you can make monsters that would otherwise look like total trash in mdl. The thought of having a large chunk (most?) of your audience just seeing the trash version anyway because of backwards compat will probably make you design the model in a conservative way to minimise this, which itself weakens the reason for doing 16-bit in the first place, so eh I ‘unno. 
For The Record I Still Like Preach’s Take On The Idea 
It seems elegant despite my above misgivings 
@preach 
wouldn't it be simple to code into the engine a search for a md3(or md2) version of the same model name? So much like the high def textures for those who want to use them.

It would mean that so long as the person modelling had released a lower poly version of the mdl too it would be available and wouldn't break vanilla compatibility. 
Or... 
you could fall back to an existing entity in the pak. If I make a new monster md3 but the engine doesn't support it, fallback to an Ogre. Have that fallback mdl definable by the mapper. 
Nevermind 
^^^^ that's stupid 
 
I still don't see how it would be possible to do the amazing effects (outside of full fledged particles a'la Maya or Blender) that Preach manages to pull off with the mdl format. I'm still at a loss on how to make polygons dissappear into themselves. 
Zero Scale 
The trick is that you take each particle, and on the frames where you want it to be invisible you apply a scaling transformation with scale factor 0 (typing the value numerically is the surest way to do it). There are variations on this, like on some models I only apply the transformation on one axis, so that the particle collapses into a line rather than a point. But it's all about scaling - it's the easiest way to ensure that all the vertices align so the polygon disappears. 
I Had No Idea... 
and this is coming from someone who usually doesn't bother playing maps in bsp2 format

This is heartbreaking. 
I Wonder 
Is there anything that would bring cause for a bsp3? 
Tris/verts Weights 
I have now made an arc_ogre, but I am faced with the problem that my splines are converted into four on each clip node when converted. The result is that a q1 model with relative weight triangles is converted to two triangles in each square. I can only save them in squares, which are converted to two triangles.
If I import this to qmle, the ratio of internal triangles has almost doubled.

Would this make much difference to a model with only half of verts / tris? As long as it stays below 1000tris / 2000verts, it should make little difference. 
Qmaster 
Sepulcher allegedly came close to hitting the upper limits, and also it did something that required a change in Quakespasm, but I don't remember what.

The 3DRealms game has some gigantic maps, but IIRC they don't use their own map format.

I suspect Bal will be the first one to break bsp2 ;-) but at that point, adopting q3bsp would probably happen first. 
Tri Limit 
Although strictly speaking some engines (e.g. unmodified GLQuake) do have a limit of 1000 triangles, the original software engines allowed 2000 triangles, and pretty much every custom engine at least restored the limit to that level. So you're probably OK to exceed 1000 if you need to. 
Qmle 
In my case it is not the tri limit, but the question if I should simplify a working model with relative high counts into one with less for benifit of better performance.
It's quiet a lot of work doing this in Qmle. 
Screenshots, Please! 
Pictures, screen captures, screenshots, views of work in progress, ... come on, make us get an hard on, Quake style! 
Barnak 
Trying to adjust maps by the hand of the first screenshots, with no dynamic light.
Sorry for the low resolution, old quake school.

when
I
only
had
low
resolution
to
see
my
quake 
Nothing Too Special 
Temple Of Doom Final Beta 
Hi everyone!

I've over worked my map and think its ready for release.
Hope that some of you can take a look on it and tell me if it works.

http://www.quaketastic.com/index.php?dir=files/tod/

gsh_tod.zip

best wishes
Gunny 
Thoughts On The Temple Again 
Below you can find my demo with comments:

http://www.quaketastic.com/files/tod/gsh_tod_esrael.zip

Having more guidance in the map was a welcome addition in this version. I also liked the little story texts. :)

I still think the map was a bit on the easy side. Especially the temple area with the yellow and red armors being so easily available, not to mention giving the player the quad damage. Maybe some of the stuff could be hidden behind secrets?

I wasn't able to exit the map this time around. I opened the map file in Trenchbroom, and it looks like the reason is because you haven't specified the next map for the changelevel trigger. You have to specify a map, or else the change level trigger won't work. (Didn't know that myself, actually. Well, the more I know, I guess.)

While having the map open in Trenchbroom I also noticed that you had used the wrong texture in the clip brushes that were supposed to prevent the player from jumping over the fence. You should use the "clip" texture, not the "trigger" texture. 
@Esrael 
Thanks again! :)

Ahh yes I forgot the armor.
Will It change something if I change the Level to normal or hard?
The exit thing is a little bit frightening cause I entert the start map for exit and never changed it? Yes it disapeared Hmmm. I changed that again.
Do you think after that last changes this is a map for release? 
1 post not shown on this page because it was spam
First | Previous | Next | Last
You must be logged in to post in this thread.
Website copyright © 2002-2025 John Fitzgibbons. All posts are copyright their respective authors.