News | Forum | People | FAQ | Links | Search | Register | Log in
Mapping Help
This is the place to ask about mapping problems, techniques, and bug fixing, and pretty much anything else you want to do in the level editor.

For questions about coding, check out the Coding Help thread: https://www.celephais.net/board/view_thread.php?id=60097
First | Previous | Next | Last
How To Create Glass? 
how to create transparent glass? 
Clear Glass 
Introduce manganese dioxide into the manufacturing process. 
Skip Tool 
... is your friend ... (but I didn;t have link in mind where you could find it)

OK, others, please correct me if I do not remember properly:

1/ Create a brush using a "plain" water texture (i.e using only one color) and name it *<watername>: this wil be your glass

2/ Create a func_wall of the exact same size, and use a skip texture there

3/ Add skip tool in your list of compilation tool, after bsp process (bsp/skip/vis/light). So ultimately the func_wall will have its texture removed but remains solid (you can't pass through it), but the "water" texture remains gicing the glass texture visual.

4/ Load the map, and adjust r_water_alpha value in the console to a value that is below 1.. the closer to 0, the more transparent the glass.

Enjoy ! 
#18429 
An alternative way is to use a solid color texture (such as grey) and make it a func_wall.

Add an alpha key with value of however transparent you want the glass (So .65 for example). 
That Will Work Too... 
... but I am not sure this is supported by all engines... not even sure the other techniques is working with all engines either.. though... 
 
https://www.quaddicted.com/reviews/mfxsp17.html

This map has an example of glass. It comes with a .map that you can look at to see how it was done. 
 
Neither technique would work with the original engines as far as I know, but I'm pretty sure that the alpha key has been a thing for a while... someone correct me if I'm wrong of course. 
 
alpha key doesn't always work as intented. I usually make teleporters' liquid a func_wall with alpha 1, but it often looks transparent anyway (I noticed that in videos/streams) 
Hmm 
Quakespasm supports seperate alpha for water/slime/lava/telefluid set in worldspawn just fyi :) 
Vertexes Limit 
What are the potential problems if exceeding the vertexes limit? I'm pretty much right at it now. However, only just noticed that I had exceeded it by roughly 4000 in MCE with no apparent downsides that I'm aware of?! 
Where Is This Information At! 
Quakespasm supports seperate alpha for water/slime/lava/telefluid set in worldspawn just fyi :)

I must have missed it. 
 
BSP 29 has a hard limit of 65536 verts, because face edges reference verts with a 16-bit unsigned integer. I doubt any qbsp will let you exceed this and still write out a BSP 29 file because the map rendering would be totally messed up if it did.

Where was the warning / limit coming from? 
@damage_inc 
http://quakespasm.sourceforge.net/Quakespasm.html#ss6.3

func_wall with alpha 1, but it often looks transparent anyway (I noticed that in videos/streams)
What engine was that with? AFAIK that is a bug, at least with the Fitzquake / protocol 666 interpretation of alpha. the Fitz 0.85 code specifically mentions that "_alpha" "0" means to use r_wateralpha for liquids, but other "_alpha" values besides 0 take precedence over r_wateralpha 
@ericw 
Thanks so much. Bookmarked! 
Ericw 
TxQbsp reports WARNING: Vertexes 33657 exceed normal engine max 32767.

But it seems there are no consequences, maybe only in software Quake. 
 
vanilla's vertex limit is 65535 apparently.
I didn't check the asm to ensure that it doesn't sign extend, but otherwise the datatypes are already unsigned and thus already 65k. 
 
What engine was that with?

Quakespasm, don't know the version, I guess the recent one. Gotta check it out myself.
Btw it was with func_illusionary, not func_wall if that matters. Works correctly in latest mark v tho. 
Question About WinQuake R_surfs And Edges 
Hi, I've been searching for some info but wasn't able to find anything conclusive. The map I'm working on is almost done, I've made some huge changes and the map is now fully playable in WinQuake, a program I've not used in... let's not say how long.

The only problem is greyflash, I know easily fixable by setting r_surfs and r_edges to say 10000, and the map runs perfect. I wan't to reduce the amount of polys being rendered so the map runs akin to and id map. Essentially max 800 surfs, 2400 edges. I am almost there, 80% of the map is below this limit.

Will doing a full vis help this? Haven't done it yet and it may take at least a day or so. Is there any other way to reduce what is rendered, I've already simplified and added "S turns." Any help is appreciated.

Thanks. 
 
I think you should have run vis first, before making huge changes. In GLQuake, vis can reduce r_speeds by a factor of 10 or more. If that has any correlation to r_surfs and r_edges in WinQuake, it may have been all you needed to do. 
 
Yeah that's what I was guessing. The reason I made changes had nothing to do with VIS. I had to reduce entities, edicts and marksurfaces to be compliant with WinQuake. I will give VIS level 4 a try though. Thank you. 
..a Health Consuming Doubt 
help guys:
I'm trying a Q1 total conversion(a true one! as Carmack stated in gpl readme) and I created my monsters totally re-skinning the standard knight model in qme.
So,in a supposed commercial release, may I use them also with the knight animations left untouched in qme ?
-my monsters don't resemble id original in any way and after all animations frames are only numeric values in qme.. not assets I guess- 
Since 
the knights are in the free shareware Quake demo (pak0.PAK), you're fine. 
Shareware Does Not Mean Free To Use 
Besides, shareware Quake may only be used to testplay the game, not used to run mods or build upon. Don't be fooled by things like nQuake and the like claiming it's all legal and "free Quake". 
2 posts not shown on this page because they were spam
First | Previous | Next | Last
You must be logged in to post in this thread.
Website copyright © 2002-2024 John Fitzgibbons. All posts are copyright their respective authors.