Func_Msgboard: TyrUtils V0.5

News | Forum | People | FAQ | Links | Register | Log in

|  | TyrUtils V0.5

Posted by Tyrann [130.220.71.24] on 2013/02/26 04:01:06

It's been a long time, but finally I have something worth releasing, so here is version 0.5 of my map utils package:
* light and vis both now multithreaded on Unix and Windows platforms
* vis now writes a state file every 5 minutes so it can resume if needed
* qbsp and vis now support a form of detail brushes, similar to Quake 2. See qbsp.txt for further details.
* added a small optimisation to vis for a minor speedup (usually only 1-2%)
* build system re-written and lots of cleanups all over the code
Please test, break and report bugs as needed :)
* Announcement
* Utils Home Page
* Download: Windows, Mac OS X, source
My website has also had an update - let me know if I broke anything and hopefully the comments function also works.

Tyrann You Own!
#1 posted by Scampie [72.12.65.92] on 2013/02/26 07:31:36
If anyone wants, I quickly added func_detail to my .ent file I use in Radiant 1.5
https://dl.dropbox.com/u/103186490...
Oh My God Oh My God Oh My God
#2 posted by Kinn [86.164.250.110] on 2013/02/26 11:30:21
Proper detail brushes!!!
Tyrann, you are the awesome.
Quick Question
#3 posted by Kinn [86.164.250.110] on 2013/02/26 11:58:03
does the qbsp support all the increased map limits and increased floating point precision that's featured in bengt jardrup's txqbsp and treeqbsp?
I Wonder
#4 posted by CarlJ [194.14.32.4] on 2013/02/26 13:10:25
Havenīt used your utils before, is this standalone or something you integrate into Radiant? Im at work now so canīt check it out
Yes
#5 posted by Tyrann [203.122.220.108] on 2013/02/26 13:13:19
This qbsp uses double precision floating point and should be able to cope with all the usual increased limits. If not and you have a map that breaks it, let me know and I'll fix it. :)
It doesn't do bsp2 yet, but it's probably not that hard to add. Will look at this soon(ish).
Thanks Scampie for the Radiant example - I'll add the func_detail snippet to the qbsp.txt file.
Nice Work ! ( And Fml )
#6 posted by rebb [80.141.89.13] on 2013/02/26 13:17:32
I swear there must have been detail-brush implementation inspiration rays from outer space at play here, since i was working on the exact same thing on a modified TxQBSP / WVis combination.
But you're the real tool programmer, so i'll probably just clean the code up a little and put it up as a package somewhere, maybe some parts of the "implementation" could be of interest.
CarlJ
#7 posted by Tyrann [203.122.220.108] on 2013/02/26 13:19:01
I'm don't know much about Radiant, but it should be possible. Hopefully someone else here can answer that one.
Rebb
#8 posted by Tyrann [203.122.220.108] on 2013/02/26 13:21:38
Hehe, ouch, yeah that kinda sucks. But I'd definitely be interested to take a look at your implementation when you're done.
Rebb
#9 posted by sock [186.108.77.104] on 2013/02/26 13:55:28
I would love to try those tools based on TxQBSP, I use lot of the extra features of the Tx toolset (-gate 1.0 -soft -softdist 8 -extra4 -anglesense 0.65) and unfortunately they seem to be missing in the Tyrann tools.
Sock
#10 posted by rebb [80.141.89.13] on 2013/02/26 14:02:31
Those seem to be light-related parameters, the detailbrush stuff doesn't need any light-tool changes as far as i'm aware.
So you should be fine using TyrUtil's BSP and VIS and Tx Light.
#11 posted by sock [186.108.77.104] on 2013/02/26 14:05:36
That would be awesome if I can mix and match the compiler tools. I assumed it would not work, I will have to do some tests.
Nice
#12 posted by negke [31.18.172.250] on 2013/02/26 14:12:13
Tyrann, how does your implementation differ from the one in the Quest tools (and rebb's)? Do detail brushes split the polygons of normal world brushes they touch?
Make sure the vis state doesn't save unfinished (open) portals like the unfixed version of Wvis did!
#13 posted by FifthElephant [82.12.230.210] on 2013/02/26 14:38:04
So in WC I can "tie to entity" on a brush and enter "detail" in the dialog box and it correctly bsp/vis properly with your tools? Also like Negke says, will this split faces of standard brushes? (I assume not)
Tyrann
#14 posted by ijed [200.73.66.2] on 2013/02/26 14:56:40
Do you want the bsp2 compilers source?
#15 posted by Willem [199.255.40.36] on 2013/02/26 17:09:29
Yeah, what are the tech details on the detail brushes? Do they cast shadows, do they cut into the world, do detail brushes cut other detail brushes, etc? Sounds neat!
#16 posted by Spirit [80.171.40.128] on 2013/02/26 17:11:57
The http://quakeforge.net/ tools also include detail brush support so for everyone playing around with them now, it would be great if you could test that as well.
I Thought
#17 posted by Kinn [86.164.250.110] on 2013/02/26 17:27:48
there was a reason no-one ever used the quakeforge stuff. damned if i can remember it though
Face Splitting
#18 posted by Kinn [86.164.250.110] on 2013/02/26 20:27:21
Do detail brushes split the polygons of normal world brushes they touch?
If they didn't split though, would that even produce a valid Quake bsp? Admittedly I'm not a guru, but I was under the impression that the best we could do in Quake would be something that drastically speeds up vis, but you'd still have to chop all the faces up. Maybe the splitting planes from the non-detail brushes could always get priority, which might reduce the number of polys split.
But ignore me, I don't really know.
What Detail Brushes Do
#19 posted by Tyrann [203.122.220.108] on 2013/02/26 21:22:55
Kinn is pretty spot on actually. Detail brushes still split the world, but they don't cause extra portals to be generated the way normal brushes would. Less portals makes vis much happier - vis gets exponentially slower with the number of portals.
The planes from detail brushes are the last ones selected for splitting planes, so that all the leafs in a detail cluster have the same parent node. Not sure if that really means you get less poly splits, but it seems reasonable that it would help.
Sock
#20 posted by Tyrann [203.122.220.108] on 2013/02/26 21:26:34
Yeah, you can use any light util - the only thing that changes is the .prt file, so the vis tool needs to understand that. But I will look at adding those options to my light util anyway (-gate, -soft, -softdist, -extra4, -anglesense).
Spirit
#21 posted by Tyrann [203.122.220.108] on 2013/02/26 21:32:36
Oh, I never realised QF had that. I'll definitely take a look. Bill writes nice clean code! :)
Tyrann
#22 posted by Kinn [86.164.250.110] on 2013/02/26 21:43:06
Heh, cool I figured that's how it would work :}
If you're thinking about updating light to use the features in bengt's tool, don't forget "delay 5"!
#23 posted by Scampie [72.12.65.92] on 2013/02/26 22:15:53
Tyrann: Could you add to your Qbsp support for floating point rotations of textures (so for instance, rotating a texture 22.5 degrees doesn't get rounded to 22 degrees)? Frib (or I guess a friend of his) added it to Bengt's modification of TreeQbsp, but it'd be nice to have with your func_details!
Some test shots, showing exactly what Tyrann just explained...
http://i.imgur.com/NHpU9eH.jpg
Here, the red textured brushes are func_detail brushes, and we can see that they still cut into the hull of the world. (the crate in the middle of the screen is a floating cube, world geometry)
http://i.imgur.com/LpQbmQU.jpg
Here you can see that that the PVS does not consider the func_detail brushes, as the floating crate cube is still rendered.
http://i.imgur.com/ajkNDg0.jpg
Here is that same view, except the red textured brushes are normal geometry, to prove that the crate would normally not be rendered in this location.
These detail brushes are good for speeding up your Vis time by simplifying the PVS. They are NOT for reducing r_speeds.
Ah
#24 posted by FifthElephant [82.12.230.210] on 2013/02/27 00:38:38
I see. I was thinking that you'd somehow managed to create a semi-solid feature that is in Unreal Engine.
Floating Point Texture Rotation
#25 posted by Tyrann [130.220.150.44] on 2013/02/27 01:28:48
Sure, will add that. Should be relatively trivial. Hint and skip are also on the todo list.
#26 posted by necros [99.227.223.212] on 2013/02/27 04:08:44
will need to play with this on the weekend!
#27 posted by FifthElephant [82.12.230.210] on 2013/02/27 10:18:43
Is there a way to put in some kind of occlusion brush in the same way that water used to be used before watervis?
Floating Point Texture X/Y Offset, Too
#28 posted by negke [31.18.172.250] on 2013/02/27 11:22:59
To keep Scampie's texturelocked trims aligned.
This
#29 posted by ijed [200.73.66.2] on 2013/02/27 13:36:59
Is great. Thanks Tyrann.
Tyrann
#30 posted by gb [46.142.37.186] on 2013/02/27 18:37:36
This is great news (I do still compile Quake 1 maps occasionally). I will add a link to your tools to my tutorials once they support the full monty.
Actively maintained tools are basically the lifeline for any kind of modding. Thumbs up.
Mac OS X Binaries
#31 posted by SleepwalkR [85.178.188.61] on 2013/02/27 19:05:01
I'll look into providing binaries for Mac OS X, would you like to host them on your site?
Mac OS X
#32 posted by Tyrann [130.220.71.27] on 2013/02/27 23:45:21
Thanks SleepwalkR - I was meaning to do that anyway so I've just done a quick build on my ML machine and thrown that up on the utils page. Does that look ok?
Any tips/advice for providing OS X binaries appreciated. I'll hopefully be doing the same for TyrQuake with the next release.
Awesome Stuff!
#33 posted by than [182.164.57.115] on 2013/02/28 14:47:02
Will definitely give these a whirl next time I compile a map.
Maybe it's just fantasy, but I'm hoping there is also going to be a map release from you this year... :)
Also...
#34 posted by than [182.164.57.115] on 2013/02/28 14:48:51
"After it took 36 days for my map to vis on a fairly decent 8-core machine I knew it was past time that we had something like this for Quake."
How long does your map take to vis now? Have you detailified it yet?
Heh
#35 posted by ijed [200.73.66.2] on 2013/02/28 15:04:45
Maybe it's just fantasy, but I'm hoping there is also going to be a map release from you this year... :)
I thought the same. Might go replay moonlight. By coincidence was looking at OUM the other day as well.
Have Not Detailified It Yet...
#36 posted by Tyrann [130.220.71.24] on 2013/03/01 00:49:22
...but working on it. 14k+ brushes! :)
Wish List
#37 posted by sock [186.108.77.104] on 2013/03/04 13:37:16
* Brush models (func_ entities) can have a minlight value so that there is no solid black surfaces. It is easy for a secret door to have a solid black surface on the opening edge, which is difficult to get rid of. No one wants to minlight a whole level but certain entity types could benefit from a minlight boast.
* Phong Shading on grouped brushwork. This would be awesome for terrains where the lighting is consistent across surface edges. It is difficult at the moment to create terrain wall sections without obvious light seams.
* AI clip brushes, a surface that is invisible like clip but can block AI/Players. At the moment all floor gaps need func_wall entities so that AI can walk across the gaps properly. For some reason clip brushes are not in the clip hull that the AI movement code uses.
#38 posted by Kinn [86.163.3.118] on 2013/03/04 13:59:11
* AI clip brushes, a surface that is invisible like clip but can block AI/Players. At the moment all floor gaps need func_wall entities so that AI can walk across the gaps properly. For some reason clip brushes are not in the clip hull that the AI movement code uses.
That's an engine issue I believe.
#39 posted by FifthElephant [82.12.230.210] on 2013/03/04 14:18:38
If we even got the first 2 things on Socks wishlist that would be incredible. Is that even possible though?
Ai Clip
#40 posted by ijed [200.73.66.2] on 2013/03/04 14:45:18
This is a C/Qc issue caused by the hull navigation.
You can solve it with an entity called a func_nodraw from the extras mod: http://www.quakewiki.net/quake-1/m...
Coding one from scratch should be trivial since you just set the model to empty on runtime, I think.
All it does is make a solid brush that you can't see. It's not ideal because you can't shoot through it - but that's the limitation of Quake.
Minlight for entities would be awesome. Q2 has this and it makes life a little bit easier every time you add a door to a map.
#41 posted by Willem [199.255.40.36] on 2013/03/04 16:00:06
<quote>* Brush models (func_ entities) can have a minlight value so that there is no solid black surfaces. It is easy for a secret door to have a solid black surface on the opening edge, which is difficult to get rid of. No one wants to minlight a whole level but certain entity types could benefit from a minlight boast. </quote>
Ooh, nice idea! That would be mega useful.
#42 posted by Willem [199.255.40.36] on 2013/03/04 16:00:28
Fucking tags.
Clippa
#43 posted by Preach [77.98.165.95] on 2013/03/04 19:51:39
* AI clip brushes, a surface that is invisible like clip but can block AI/Players. At the moment all floor gaps need func_wall entities so that AI can walk across the gaps properly. For some reason clip brushes are not in the clip hull that the AI movement code uses.
To be more specific about what the map compiler does which causes problems - the clip brushes get added to hull-1 (player size) and hull-2 (shambler size), but not the visible hull or hull-0 (point sized). I'm pretty sure that the visible hull and clipping hull-0 are stored separately in the BSP (but please correct me if I'm wrong).
If that's the case, then it should be possible to create clip brush variants where the brushes are considered in different stages. So for example super-clip brushes would be skipped at the visible stage, but included in hull-0 to hull-2, so grenades bounce off them and monsters can navigate them. It certainly ought to be possible to create sub-clip brushes which only affect hull-2, to prevent large monsters getting into parts of the map but allowing players in.
It's "mangled Tags Monday"
#44 posted by Preach [77.98.165.95] on 2013/03/04 19:52:15
Get in
Ideas
#45 posted by Tyrann [130.220.71.24] on 2013/03/04 23:36:57
Entity minlight - Easy. Will add that.
The AI clip thing, don't think it's possible. The thing is that Hull0 *is* the visible hull. There is no separate clipping hull for point size entities, they use the same bsp tree that the renderer uses.
Phong Or Some Kind Of Smoothing
#46 posted by Tyrann [130.220.71.25] on 2013/03/04 23:41:30
It should be doable, but the information about which brushes are grouped are lost after the BSP has been produced, so can't use that as a basis.
A tweakable command line parameter (or worldspawn key) to set the maximum angle between two surfaces to consider for phong shading/smoothing should work and I believe there are Q2/Q3 tools that did this (though I forget the name now). Could also restrict it to faces with the same texture as well if that seems like a useful thing to do.
#47 posted by metlslime [159.153.4.50] on 2013/03/04 23:41:57
recommend you call it "_minlight" since the engine automatically ignores keys that start with an underscore (this is so you can add new fields for the compilers that don't have to be in the progs.dat definitions list.) Otherwise players will get spammed with "minlight is not a field" messages.
Phong Shading
#48 posted by Kinn [86.163.3.118] on 2013/03/04 23:53:42
Hmmm...some way of specifying it to only use phong shading on faces that use certain textures might be a good idea...
Whilst we're all in crazy wishlist mode - what about an option for brush entities to cast shadows (on the world and other brush entities)
#49 posted by sock [186.108.77.104] on 2013/03/04 23:55:11
@Tyrann, doing phong shading on surfaces with the same texture would be awesome. Another option is to use a keyword in the texture name. Maybe you can specify the keyword as a parameter.
Example command line : "-phong terrain" Textures containing the word "terrain" have phong shading applied to their edges.
Having the _minlight key on any entity would be awesome, I can think of plenty of situations where that would be handy.
Phong Shading Texture...
#50 posted by FifthElephant [82.12.230.210] on 2013/03/04 23:57:18
Or have it identify with certain texture names? Like how fluids begin with an * or animated textures begin with a + ?
#51 posted by FifthElephant [82.12.230.210] on 2013/03/04 23:59:50
If we have phong shading and minlights we could emulate Quake 3's shading on curves really accurately? This would be amazing!
#52 posted by Spirit [80.171.9.227] on 2013/03/05 00:13:43
aguirre's tools have the anglesense parameter, maybe that is related?
#53 posted by sock [186.108.77.104] on 2013/03/05 00:21:46
I already use anglesense, but unfortunately it is applied to everything which makes it difficult to fine tune.
Faking Clips
#54 posted by Preach [77.98.165.95] on 2013/03/05 00:45:45
The AI clip thing, don't think it's possible. The thing is that Hull0 *is* the visible hull. There is no separate clipping hull for point size entities, they use the same bsp tree that the renderer uses.
Ah, was worried you'd say that. Still, if we can have brushes that are both skip AND detail, we can fake it. Imagine we're just trying to create 1 solid transparent window in a visible square frame. On the front of the frame we make a square based pyramid, so that the four vertices of the base meet the vertices of the frame, and the point of the pyramid points backwards.
This brush doesn't clip away any of the inside of the frame, because it only touches the edges of the other surfaces. Make it skip and you've got an invisible hull-0 face. You can already do this much with the existing skip tool.
Naturally the next thing would be to make another brush on the back of the frame, so the window clips correctly from both sides. The problem to date is that sealing the area on both sides causes it to be clipped away. Even if one side is left open, VIS believes the skip brushes are opaque and starts culling the inside of the frame when looked at from the front. I think that making these brushes details as well as skip ought to fix both problems at once - but I should probably put my money where my mouth is and try it!
Nice Idea!
#55 posted by Tyrann [130.220.71.26] on 2013/03/05 01:28:11
Preach: yeah, I think that might just work! :)
Sock
#56 posted by Spirit [80.187.102.242] on 2013/03/05 08:05:29
you can specify it per light entity, not only globally
Procrastinating
#57 posted by Spirit [80.171.9.227] on 2013/03/05 16:52:44
Is it me or Wine or does this vis totally kick wvis' ass?
I just vis'd EvilExhumed.bsp in 70 seconds with this vis, but with wvis in wine it took 12 minutes!
#58 posted by Spirit [80.171.9.227] on 2013/03/05 17:07:19
Let's do some benchmarking in any case, I always wanted to do that.
https://www.quaddicted.com/tools/v...
#59 posted by Spirit [80.171.9.227] on 2013/03/05 17:09:04
Damn link abbre.....
That link above invites you to run some VIS on gmsp3v2.bsp and has a table where you then can add your numbers.
#60 posted by Willem [199.255.40.36] on 2013/03/05 18:00:34
[quote]I just vis'd EvilExhumed.bsp in 70 seconds with this vis, but with wvis in wine it took 12 minutes! [/quote]
Srsly? Damn, that's great! I wonder what he did to his version ... whatever it is, somebody pour more in. :)
#61 posted by Willem [199.255.40.36] on 2013/03/05 18:01:34
Jesus FUCK with this non-standard tags...
I just vis'd EvilExhumed.bsp in 70 seconds with this vis, but with wvis in wine it took 12 minutes!
Srsly? Damn, that's great! I wonder what he did to his version ... whatever it is, somebody pour more in. :)
#62 posted by Spirit [80.171.9.227] on 2013/03/05 18:18:49
I added qfvis and bjp to the wiki page.
Could someone make a bat file that runs it all without the need for interaction? The only parameter the user has to supply is the number of threads for qfvis, the other tools pick them themselves.
#63 posted by FifthElephant [82.12.230.210] on 2013/03/05 18:34:53
Is this some additional thing on top of normal vis? If not you could run it with necros compiling tool without having to mess around with batch files?
#64 posted by gb [46.142.22.226] on 2013/03/05 19:21:28
If some Quake 1 tool gets phong shading, Q1 mapping would suddenly look more attractive again.
Higher resolution lightmaps? :-p
#65 posted by gb [46.142.22.226] on 2013/03/05 19:23:57
... dirtmapping... ok, I'm dreaming. Nevermind.
Ambient Occlusion!!
#66 posted by Kinn [86.153.126.205] on 2013/03/05 19:26:12
didn't necros make some interesting progress on ambient occlusion a while back?
Spirit
#67 posted by spy [178.88.21.209] on 2013/03/05 19:43:12
tyrvis
---- TyrVis v1.0 ----
running with 4 threads
BSP is version 29
4040 leafs
10656 portals
Calculating Base Vis:
0....1....2....3....4....5....6......
Calculating Full Vis:
0....1....2....3....4....5....6......
average leafs visible: 181
c_noclip: 0
c_chains: 158170515
visdatasize:282459 compressed from 2040200
Writing BSP version 29
144.0 seconds elapsed
=================================
---- WVis 2.31 ----
Modified by Bengt Jardrup
Multithreading enabled by Willem
File: gmsp3v2.bsp
4040 portalleafs
10656 numportals
testlevel = 4
Using 4 threads.
average leafs visible: 176
max leafs visible: 518 near (384 2240 -768)
c_chains: 113742805
visdatasize: 270 kb compressed from 1992 kb
Elapsed time : 4:00
==================================...
qfvis
i gave up after 15minutes
--------------------------------
specs - i-760 -4gb ram -win7 x86
#68 posted by Willem [199.255.40.36] on 2013/03/05 19:45:20
average leafs visible: 181
average leafs visible: 176
That's interesting. I wonder what the difference is...
#69 posted by Spirit [80.171.9.227] on 2013/03/05 19:57:55
Spy, thanks! I guess that is a "i5 760", correct?
qfvis seems to get stuck (or it is ultra slow) for some reason, I'll tell taniwha.
I noticed that vis leafs difference too, different methods?
Yeah
#70 posted by spy [178.88.21.209] on 2013/03/05 20:06:48
"i5 760"
'c_chains' also look different to me
AO
#71 posted by DaZ [2.99.114.115] on 2013/03/05 22:48:17
could look really cool in Quake. I know valve added AO to the light compiler for CS:GO maps so maybe that would be somewhere to start looking? I have no idea :P
Average Leafs
#72 posted by Tyrann [130.220.71.26] on 2013/03/05 22:49:52
That is interesting. I'm not aware of anything in my vis that should give a different result. It could just be a floating point precision thing, but I suspect it's more than that. I'll look into it at some stage, but it will be pretty tedious.
#73 posted by Willem [108.228.244.211] on 2013/03/06 00:46:42
I can't imagine that it's worth your time. :) Your VIS works, so be it...
TyrUtils V0.6
#74 posted by Tyrann [203.122.220.108] on 2013/03/07 09:42:46
Maybe a moderator could update the post above, rather than a new annoucement?
Quite a few new features here, thought people might rather have some of this stuff now while playing around with Trenchbroom (func_group in particular):
TyrUtils v0.6 changes:
qbsp: respect floating point texture rotation and shift in map files
qbsp: support for Valve's 220 map format used in later Worldcraft/Hammer
qbsp: support func_group entities used by Radiant and similar editors
qbsp: surfaces with the skip texture are now removed from the compiled bsp
qbsp: hint brush support similar to Quake 2 for hand-tweaking the PVS
qbsp: fixed a problem where leak files were not written for hull0 or hull1
light: fixed a race condition in multithreaded coloured light processing
light: fixed bug preventing use of all 4 light styles in a common case
light: implemented attenutation formulae "delay" 4+5, ala Bengt's tools
light: removed old bsp30 support
light: lit files now automatically generated when coloured lights detected
light: implemented 4x4 oversampling with -extra4 command line
light: implemented the -gate option to help speed processing (default 0.001)
light: implemented the "_softangle" key for spotlights
light: implemented minlighting for brush models
Announcement
Download: Windows, Mac OS X, source.
Good Stuff
#75 posted by SleepwalkR [130.149.243.224] on 2013/03/07 10:16:17
and thanks for supporting the Mac!
Neat...
#76 posted by FifthElephant [82.12.230.210] on 2013/03/07 10:48:23
I'll test out the new things today :)
So....
#77 posted by Scampie [72.12.65.92] on 2013/03/07 11:07:10
how do hint brushes work? do you literally just texture a brush in a texture named 'hint'? or are they func_hint? didn't see anything in the readme
Hint
#78 posted by Tyrann [203.122.220.108] on 2013/03/07 11:13:35
Yeah, just a texture named hint. I'll add something to the docs for that.
I need to double check, but as I understand it, skip means something different in Q2/Q3 (just a face that gets removed completely) and "caulk" is what we have been using as skip.
Should I make "caulk" to replace skip, make "skip" like the Q2/Q3 skip and add a command line option "-oldskip" so it can be backwards compatible? Hrm...
God Forbid
#79 posted by FifthElephant [82.12.230.210] on 2013/03/07 11:22:51
That I finish this map... I have no idea how to optimise for Quake 1. I've just been throwing brushes all over with now consideration for how to make it run quick. (it's starting to slow down DirectQ, not fitzquake though)..
Skip/caulk
#80 posted by Kinn [86.153.126.205] on 2013/03/07 11:52:24
I need to double check, but as I understand it, skip means something different in Q2/Q3 (just a face that gets removed completely) and "caulk" is what we have been using as skip.
So, currently "skip" in your tools is a face that gets removed once the bsp has been compiled. Skip in the Q2/Q3 sense would remove the face at an earlier stage - at what stage can this be done in quake bsp without breaking the compilation process and what would the uses of it be?
#81 posted by necros [99.227.223.212] on 2013/03/07 12:47:38
That's me question too. Ideally, it would be best not to change the names of the commands this late.
#82 posted by Scampie [72.12.65.92] on 2013/03/07 13:14:50
hmm... that is weird yeah, because q1 skip is 'solid nodraw' like caulk and skip in the q2/q3 sense was 'nonsolid nodraw' to be used with hint brushes.
a fine mess this has caused!
Q2/q3 Skip
#83 posted by Kinn [86.153.126.205] on 2013/03/07 13:22:25
Unless I'm mistaken then wasn't the only use of q2/q3 skip to flag all the non-hint faces of hint brushes?
If that is true, then it strikes me as redundant because I would have thought the better thing to do in that case would be to just detect if the brush has any hint face on it, flagging it as a "hint brush", and then just ignoring that brush for the purposes of building the bsp (except when using the hint face to create the splitting planes). In that case, the non-hint faces aren't used anyway, and therefore don't need explicitly flagging as skip.
Is there another usage of q2/q3 skip that i'm missing?
Also
#84 posted by Kinn [86.153.126.205] on 2013/03/07 13:28:47
Tyrann, you have earned 1000 of my finest golden manbabies for that recent update.
Still can't believe after all these years we've suddenly got a new suite of awesome, actively developing compile tools.
Well
#85 posted by Scampie [72.12.65.92] on 2013/03/07 13:34:05
what I think makes q2/q3 skip mostly redundant is that I believe 'trigger' does basically the same thing: nodraw, nonsolid, doesn't cut bsp faces. if hint and trigger play nicely in q1 (I haven't tested) I suggest we just do that.
Wait I'm Dumb
#86 posted by Scampie [72.12.65.92] on 2013/03/07 13:34:40
trigger don't do shit in q1.
Skip/Hint/Caulk
#87 posted by Tyrann [130.220.71.26] on 2013/03/07 22:46:03
Ok, I don't think I'll mess with the skip convention now (all my fault!)
I might just make caulk also work the same and then add hintskip to be used as the non-hint faces of hint brushes.
Using Minlights!
#88 posted by FifthElephant [82.12.230.210] on 2013/03/07 23:50:12
In my WIP map, it's pretty good for my moving platforms/doors... are you still working on phong shading?
Also, is the switch for func_group just -group? Is it supposed to work for brushes?
Func_group
#89 posted by Tyrann [130.220.71.25] on 2013/03/07 23:59:13
No special switches needed for func_group - the brushes are automatically compiled into the worldspawn model.
I don't suppose there's any call for a "-nogroup" option? I couldn't think of a good reason.
#90 posted by gb [46.142.7.126] on 2013/03/08 00:08:10
IIRC, a couple years back I found a weird tool-related phenomenon. I studied maps in engines that support locking the PVS to see how effective the culling was (some of my RMQ maps were pretty heavy and I was looking to optimize the vis blocking).
I remember comparing maps compiled from several different tools, and a few of them definitely had more effective culling than others.
Can't remember the exact differences (tools tested were at least hmap2, Tryutils and AguirRe's tools), but it's worth doing a test like that. You might be surprised.
Not sure how much use hint is in Q1bsp tbh - don't q1 tools generate more portals/better culling than eg q3map2 anyway? It seemed that way when I recently tested q1bsp vs q3bsp of my converted maps in an engine that supports both. The performance of the q1bsp versions was a lot better, while I had to manually insert hint portals into the q3bsp versions to make them run equally fast.
I Should Have Asked Sooner...
#91 posted by FifthElephant [82.12.230.210] on 2013/03/08 00:13:33
I thought I was doing something wrong again (and I was, but it was a whole different kind of wrong!), not much of my hair left to pull out now!
Simulated Real-time Lighting Effects
#92 posted by FifthElephant [82.12.230.210] on 2013/03/08 00:57:52
Is there any other way of setting light attenuation/fade than using wait and delay? I'd much rather use these two things for wait/delay than to set the radius etc for the lights.
For example, I have a button on my map that when activated moves a lift downwards (that has lights on it), by timing it correctly I could simulate the light source moving downwards and then going back upwards. However because the settings are tied to wait/delay it doesn't work properly... Does this make sense?
Simulated Real-time Lighting Effects Part Deux
#93 posted by FifthElephant [82.12.230.210] on 2013/03/08 01:31:57
I made a video showing what I mean... If you changed the name of the delay/wait to something else I could actually use delay/wait to make the light reappear when the platform returns, thus simulating a kind of real-time light effect. -
http://www.youtube.com/watch?v=Mdv...
#94 posted by Tyrann [130.220.71.25] on 2013/03/08 01:33:03
Do those keys even work that way on lights?
Another way to do it is to trigger via a trigger_relay and set the delay on that instead.
I'm Using...
#95 posted by FifthElephant [82.12.230.210] on 2013/03/08 01:38:16
trigger_multiple to trigger both the platform AND the lights.
I'm pretty much a newb when it comes to the more advanced triggers so I don't know if the delay/wait was used for attenuation for some technical reason, I thought it was kind of strange.
I'll try and figure out how to make the trigger_relay do what I need it to do.
Delay/Wait
#96 posted by Tyrann [130.220.71.25] on 2013/03/08 01:46:46
The use of the wait key started with Argh!lite many moons ago. At the time I don't think the community realised that any key starting with an underscore would be ignored by the engine, so we tried to grab existing keys that were unused for lights to avoid engine warnings.
Trigger_relay
#97 posted by FifthElephant [82.12.230.210] on 2013/03/08 02:02:34
only works if I could allow the trigger_multiple to trigger multiple targets (ironically).
So it could trigger the platform & the trigger_relay, then the trigger relay resets the light (but NOT the platform as it has a different name)...
I just tested it and the trigger relay ends up infinitely resetting the platform/lights.
Hmmm...
#98 posted by FifthElephant [82.12.230.210] on 2013/03/08 02:24:09
Ok after a bit of web research it looks like I'm right in thinking that it wont work without multiple targets. Although RMQ seems to support this feature...
http://kneedeepinthedoomed.wordpre...
".target2, .target3 : Multiple targets
As in Quoth and Custents, you can trigger more than one target now with a single trigger. You can have up to six targets and two killtargets."
Bah, I was going to make a quoth version anyway at some point... I suppose I could make a "plain" version for standard quake for the time being. ;)
#99 posted by necros [99.227.223.212] on 2013/03/08 03:40:35
RMQ (and Quoth and Custents) are mods which is why you get additional functionality.
Since this is your first Q1 map (?) I would caution you to stick to normal quake until you get comfortable with how entities and the engine interact.
Or jump right in... my first release was a mod. It sucked though, so not a great example.
Necros
#100 posted by FifthElephant [82.12.230.210] on 2013/03/08 09:53:52
I'm a serial offender for not finishing maps... though I usually run out of steam/patience about now but TrenchBroom is continuing to be enjoyable.
My first actual level for Quake 1 was a trench-warfare style map I made in the 90's with an editor called Thred. It really sucked hard.
I'll make two versions, one for quake and one for the quoth mod. I thought of some really cool scripted ideas last night that I could set up with the relays.
#101 posted by Spirit [80.171.96.95] on 2013/03/08 12:49:25
Please make the utils output a trailing newline! Borking the terminal is annoying.
#102 posted by Spirit [80.171.96.95] on 2013/03/08 12:54:55
Might be the marksurfaces maybe?
$ wine bjp\ May\ 2006/Bspinfo.exe -prt cda.bsp
---- BspInfo 1.27 ---- Modified by Bengt Jardrup
cda.bsp
10439 planes 208780
33815 vertexes 405780
13782 nodes 330768
12871 texinfo 514840
26848 faces 536960
27641 clipnodes 221128
7878 leafs 220584
35183 marksurfaces 70366
119544 surfedges 478176
63331 edges 253324
137 models 8768
138 textures 1667656
lightdata 835596
visdata 1380694
entdata 71148
WARNING: Marksurfaces 35183 exceed normal engine max 32767
5238 vis leafs
18510 vis portals
$ vis cda.bsp
---- vis / TyrUtils v0.6-5-gd6ef234 ----
running with 4 threads
BSP is version 29
5238 leafs
18510 portals
Calculating Base Vis:
0....1....2....3....4....5....6......
Calculating Full Vis:
0..************ ERROR ************
\
CheckStack: leaf recursion
#103 posted by Spirit [80.171.96.95] on 2013/03/08 12:55:21
base vis finished without problems of course, stupid func
#104 posted by necros [99.227.223.212] on 2013/03/10 00:24:39
Could you support the -noambient, -noambientwater, -noambientslime, -noambientlava switches?
These remove the markers that get applied to visibility areas that cause quake to play the sky and water looping sounds.
Lod Experiment
#105 posted by mechtech [65.190.158.200] on 2013/03/10 18:06:59
I had done a small map using textures from Sock's website. Totally too much detail for vis.exe. Now with func_detail it works. vis in 135 seconds! Looks good, texture alignment stayed correct.
Gone are the days of poorly lit func_wall for details.
http://www.quaketastic.com/upload/...
Tyrann Thank you
I'm sure your tools will cause more work for everyone with a WIP map.
#106 posted by necros [99.227.223.212] on 2013/03/11 01:58:46
I haven't had to chance to really see func_detail in action yet, but your shot shows it off well (or rather doesn't show) since I can't tell what's detail and what's world. :)
Stuff
#107 posted by Tyrann [203.122.220.108] on 2013/03/11 10:42:18
Spirit: Thanks, I'll try to reproduce the error tomorrow and fix.
necros: sure, will look into that.
mechtech: looks nice!
Func_detail Test
#108 posted by mechtech [65.190.158.200] on 2013/03/11 23:57:11
Textured normal
http://www.quaketastic.com/upload/...
Shows what I used as func_detail
http://www.quaketastic.com/upload/...
Vis on this room would be useless. func_detail lets the mapper choose to not vis areas that are not occluded.
..
#109 posted by FifthElephant [82.12.230.210] on 2013/03/12 00:22:17
"It's very pretty, Bishop, but what are we looking for?"
Hammer Wad Format
#110 posted by Preach [77.98.165.95] on 2013/03/12 22:41:10
Hi Tyrann! Thanks for putting the new version together with map 220 format support. I've tested the scheme I outlined for creating a solid, invisible window and it does work!
Unfortunately I have generated another feature request in the process...the Hammer editor works with a different wad format at the same time as map 220 - basically so it can have full colour wad files. So when I go to compile my map, it can't use any of the wads. My cunning plan to use a batch file to swap the wads for Q1 format ones didn't work - Hammer locks those files while running. So I am reduced to begging for more features, sorry to say.
WAD3
#111 posted by Tyrann [130.220.71.25] on 2013/03/13 01:58:45
@Preach: didn't seem too difficult; care to try out this snapshot and let me know if it's okay? (I don't have any such files handy)
http://disenchant.net/utils/snapsh...
CheckStack: Leaf Recursion
#112 posted by Tyrann [130.220.71.27] on 2013/03/13 04:14:42
@Spirit: BJP tools have the same problem with this generated .PRT file, except the BJP defaults to "-level 4", where I default to "-level 1". I suspect it's just a bad bsp->prt conversion job.
I wonder if you were specifying "-level 4" earlier when benchmarking, because that could explain those differences too.
I should probably default to -level 4 too. Any objections?
#113 posted by necros [99.227.223.212] on 2013/03/13 11:56:56
Aren't level 1 to 3 mostly broken?
#114 posted by Spirit [80.187.111.39] on 2013/03/13 12:25:24
i could swear it said level 4 when I ran it without arguments. will check later.
Vis Test Levels
#115 posted by mechtech [65.190.158.200] on 2013/03/13 14:59:58
I think the -level thing may be numbered wrong.
-level 4 takes 95 seconds. -level 1 was nearing an hour before I quit. I checked the .prt file and found the prt2 header.
my original test was done on -level 4 so maybe func_detail isn't the fix I thought it was.
Maybe I did something wrong checking....
It's Unlikely Tyrann Would Mix Them Up
#116 posted by onetruepurple [91.240.47.30] on 2013/03/13 15:24:25
On some occassions, level 1 can take longer than level 4 indeed.
All Good Then Thanks
#117 posted by mechtech [65.190.158.200] on 2013/03/13 15:48:19
Wad 3 (.hlwad)
#118 posted by quaketree [76.14.42.216] on 2013/03/13 17:51:18
I'm having the same issue with Hammer 3.3. When I compile using your qbsp the editor spits out an error message saying that the wad is not a wad file and the level compiles with no textures at all. However when I use another BSP tool (TXqbsp) the problem goes away and all is right in the world again (only with none of the extra features like detail brushes (which is why I switched over to your's in the first place.
The link to the snapshot above is borked so I can't try it.
What Happens If
#119 posted by RickyT23 [86.149.175.67] on 2013/03/13 17:53:39
You use an actual .wad file version of the .hlwad file for compiling?
In other words you have quake.hlwad and quake.wad in the same DIR, where they both have the exact same textures inside.
Ricky
#120 posted by quaketree [76.14.42.216] on 2013/03/13 17:55:51
I do have both in there actually as a matter of course. That way if I wanted to change the .wad using TexMex I could change both at the same time.
Hmmm
#121 posted by RickyT23 [86.149.175.67] on 2013/03/13 18:01:50
This is hacky - but if you load the .map file into a text editor, you could check that the path of the wad is set to blah...yourwad.wad wather than blah.....yourwad.hlwad.
I'm speculating here, but that might work?
It might not work either, IDK :P
I Gave That A Shot...
#122 posted by quaketree [76.14.42.216] on 2013/03/13 18:11:47
and hammer ends up changing it back to .hlwad in the .map file. Even when I don't save or export after I made the changes from .hlwad to .wad.
Drive Or Text Editor
#123 posted by mechtech [65.190.158.200] on 2013/03/13 18:15:48
Hammer adds the wad info without drive letter.
You could have the HL version on drive c: and the Q1 version on d: with the same path naming.
"wad" "\quake\qconverter\sockq.wad "
Or text editor Hammer uses sock.wad I just change the "wad" entry to sockq.wad.
Hacky yes
#124 posted by necros [142.245.193.1] on 2013/03/13 18:18:33
I think the -level thing may be numbered wrong.
-level 4 takes 95 seconds. -level 1 was nearing an hour before I quit. I checked the .prt file and found the prt2 header.
my original test was done on -level 4 so maybe func_detail isn't the fix I thought it was.
Maybe I did something wrong checking....
No, that's what I meant about it being broken. You never ever want to run -level 1 to 3 because they take longer and are not as good as level 4.
Tester
#125 posted by Preach [77.98.165.95] on 2013/03/13 20:03:07
Hi tyrann! Tried to download from your link but it's 404. I also tried to second-guess what was wrong and go to:
http://disenchant.net/files/utils/...
That gave me a 403 error instead. Ready and willing to try it though!
#126 posted by Spirit [80.171.53.201] on 2013/03/13 20:20:18
Poop, it really did not default to level 4 indeed. Yes, please change that!
spy, necros, DrLabman, please re-run and update the table. ;)
Still fast!
Using .wad Vs .hlwad
#127 posted by quaketree [76.14.42.216] on 2013/03/13 20:42:15
So it works fine from the command prompt and regular .wad files after I changed the .map file to remove the hl from hlwad (that was the only changes I made to the .map file using notepad). So as near as I can tell the issue is in being able to read hlwads (WAD3 I do believe). So worst case situation I guess I can make something in Hammer, and then turn what I can into detail brushes once it's close to being done.
I will still make a shit map though... so there is that. :P
Yay!
#128 posted by RickyT23 [2.216.134.182] on 2013/03/13 20:56:22
Fixed Snapshot Download
#129 posted by Tyrann [203.122.220.108] on 2013/03/13 21:45:49
Sorry about that, b0rked the original link and had a directory permissions problem on the actual upload as well. More coffee next time! :)
http://disenchant.net/files/utils/...
Snapshot
#130 posted by mechtech [65.190.158.200] on 2013/03/13 21:57:08
wad3 working Thanks again
Yup
#131 posted by Preach [77.98.165.95] on 2013/03/13 22:19:29
I concur. And that detail-skip thing now works perfectly, for entity-free glass in maps.
#132 posted by NotoriousRay [74.107.82.97] on 2013/03/13 23:15:14
Preach- can you elaborate? Been out of the scene for a while- how would I use these tools to get entity-free glass?
Glass Demo
#133 posted by Preach [77.98.165.95] on 2013/03/13 23:50:50
Here's a demo map:
http://www.quaketastic.com/upload/...
The trick relies on a "detail" brush which is "skip" textured (which wasn't possible before tyrann's compiler). Skip prevents the brush from being rendered, and detail keeps it out of visibility calculations.
We start with a frame for our glass built out of regular brushes. A naïve attempt would build a single rectangular detail brush to fill the frame and give it the skip texture. The problem is that the insides of the frame will still get clipped away by the detail-skip brush, so there's a visible gap in the level.
The fix is to build our detail-skip brush in such a shape that it doesn't clip anything away. In the example map each side of the window pane comes from a different brush. Each brush is a square-based pyramid, with the square face exactly filling the frame of the window, and with the apex of the pyramid sitting in the space inside the window (we don't care too much what happens in there because it's out of bounds).
You could pretty much do this already with just a func_wall covered in skip textures, the innovation is that you don't use an entity any more. In theory this also makes the trick mod-neutral, although in practice mods which don't support func_wall are vanishingly rare.
DM/SP Only Walls...
#134 posted by FifthElephant [82.12.230.210] on 2013/03/14 00:10:20
I can't figure out how to make walls only appear in SP or DM only. Any ideas? I've tried to change the check the DM spawnflag for invisible walls (as a clip brush entity) but it clips no matter what mode.
#135 posted by NotoriousRay [74.107.82.97] on 2013/03/14 00:32:22
Ah, I see what you mean, thanks for that. I thought you meant glass as in semi-transparent, not a see-through solid, like apsp2 which appears to just be relying on wateralpha and a gray textured liquid turned func_wall.
Snapshot...
#136 posted by quaketree [76.14.42.216] on 2013/03/14 01:03:48
Fixed the issue for myself as well. Thanks Tyrann!
#137 posted by quaketree [76.14.42.216] on 2013/03/14 01:11:29
I suppose that you could also use the skip\detail trick to apply a shadow with no obvious source like the Quake symbol in e1m3 (I think?)instead of making a skybox and then tying func_illusionary to a sky brush to hide it.
5th
#138 posted by ijed [200.73.66.2] on 2013/03/14 15:51:07
Not sure I understand the issue, but if its a func_wall then NotDM should work no problem.
The inverse is applying the easy/medium/hard flags.
Could be that the detail faces are added to the map regardless of any entity controls though.
#139 posted by FifthElephant [82.12.230.210] on 2013/03/14 16:03:14
I set the spawnflag for the func_wall as 1792 but it refuses to compile. I'm trying to make it so that the level will work in both SP and MP like the original Quake Maps did. Here's what happens when I compile -
http://s12.postimage.org/a47u1tqxp...
Ah
#140 posted by ijed [200.73.66.2] on 2013/03/14 16:25:52
It leaks. Just guessing, but I think this is the issue - func_walls don't block vis, so you can't have them between you and the void, only solid brushes can be your level structure.
And
#141 posted by ijed [200.73.66.2] on 2013/03/14 16:26:24
For some other reason the leak is causing the bsp not to be built.
Can't Be So!
#142 posted by FifthElephant [82.12.230.210] on 2013/03/14 16:52:07
and the reason I say this is that it gives the leak errors on successful compiles (the map isn't finished yet and there are areas open to the void).
I think there's another problem at work, I'm using spawnflag 1792.
Fifth
#143 posted by negke [31.18.175.98] on 2013/03/14 19:04:56
You can't have funcs consist only of clip brushes - there need to be visible brushes (i.e. brushes with visible textures, skip works too) to define the models' boundaries. Add a small brush in the bottom left corner and another one in the top right corner in order to determine the entity's length, height and width. Those brushes should to be outside the actual room (inside floors/walls) so they aren't visible. Of course you can also make a frame around the whole wall and have the clip brush inside. This will create a dynamic wall which blocks players and monsters, but not shots and visibility.
Neg..
#144 posted by FifthElephant [82.12.230.210] on 2013/03/14 20:31:49
well it's a shame then, I'll probably have to find another solution to the problem. I'm not sure exactly how this works because I have a platform which has clip brushes on it that works, but when I tried to block off the doorway in the same fashion it doesn't clip.
#145 posted by rj [82.9.177.217] on 2013/03/14 20:44:22
he means you can have clip brushes in func_items, but only if you have textured brushes within the same entity. hence the clipped plat working (whereas a plat made entirely of clip wouldn't work)
Clip Entities
#146 posted by Tyrann [203.122.220.108] on 2013/03/14 20:54:00
Hmm, I will have another look at that to see if it can be made to work. If all brushes are clip then there will be no brushes for the entity in hull 0. There's probably a way to make that work...
Are you sure you want a func wall that blocks movement but not bullets? That's what clip will do.
Yes...
#147 posted by FifthElephant [82.12.230.210] on 2013/03/14 21:50:30
the reason being is that one side the corridor will be blocked off by boxes to the level (for deathmatch) but on the other side will be the singleplayer entrance. It's not even a big deal, I thought I could make it dual-function but it's not like anyone really plays DM that much these days.
Doesn't Matter
#148 posted by FifthElephant [82.12.230.210] on 2013/03/14 21:59:05
I've made duplicate brushes for the doorframe and put the clip brush in the middle and it seems to work now. A weird solution to the problem but it works so I wont need to release the same map twice.
#149 posted by necros [99.227.223.212] on 2013/03/14 23:34:40
I think it happens because the bounding box is based on the visual model when it is loaded by the engine, and the engine only checks collision within the bounding box.
Necros:
#150 posted by metlslime [159.153.4.50] on 2013/03/15 00:27:55
Sort of, but I think qbsp actually generates the bounding box. And the engine just accepts what qbsp generates.
I tried fixing this in the bmodel loader in fitzquake but it never seemed to work quite right and i moved on to other things.
FYI:
#151 posted by metlslime [159.153.4.50] on 2013/03/15 00:38:40
You can find my attempted fix in the fitzquake source as Mod_BoundsFromClipNode(), which is currently commented out because it didn't work.
#152 posted by Tyrann [130.220.71.25] on 2013/03/15 01:53:36
Yes, I think it's not possible to fix the bounds in the engine because the necessary information was thrown away at compile time. The fix in qbsp is actually pretty trivial. Fixed for TyrUtils version 0.7.
Clip-only Entities
#153 posted by Tyrann [130.220.71.25] on 2013/03/15 05:24:16
@FifthElephant: Give this snapshot a try.
Tyrann
#154 posted by quaketree [76.14.42.216] on 2013/03/16 20:59:59
Running light on a very small map as a test. -extra works fine but...
* Could not execute the command:
"C:\Program Files\Worldcraft\quaketools\tyruti... -extra4" "c:\quake\id1\maps\h1b"
* Windows gave the error message:
"The operation completed successfully."
I... I... I just don't know what to say (the operation completed successfully is an error? WTF is THAT all about? I think Windows is drunk again). The map then loaded just fine in Quakespasm minus light being run at all (fullbright). So then I tried -soft 2 and had the same result. Just to narrow it down I ran just light on the compiled .bsp using the command prompt bypassing WC 3,3's automatic compiling and it worked fine. I don't if that's something that you can fix or not but I thought I'd mention it. The extra features are very nice though.
Wc3.3 set up using the Quake Adapter. Your light v0.6.35 (the last snapshot that you put up). Note that -extra worked just fine using WC's compiling console.
#155 posted by Tyrann [203.122.220.108] on 2013/03/17 00:49:33
Ok, that's pretty odd. Can you paste that info into pastebin so it's not cut off on the board. Not sure if you somehow had quotes around the util and the command line parameters, which would cause problems. E.g.
"light.exe -extra4" "C:\...\blah.bsp"
vs.
"light.exe" -extra4 "C:\...\blah.bsp"
Path
#156 posted by quaketree [76.14.42.216] on 2013/03/17 14:12:50
Ok. I forgot about F_M's cutting off of long paths. To recreate it was:
In Worldcraft 3.3 what I did was to go to:
Tools > Options > Build Programs > RAD Executable and put in (spaces are added before each "\" for here):
C: \Program Files \Worldcraft \quaketools \tyrutils-0.6-35 \bin \light.exe
This is what WC normally generates in it's built in compiler when you set it up and it works just fine.
To that I added [space]-extra4
Then I went to File > Run and made sure that the extra option was turned off (normal was ticked instead) And it failed to generate a lightmap and gave the warning that I mentioned above:
* Windows gave the error message:
"The operation completed successfully."
In the WC window that normally appears during a compile.
The same thing happened with [space]soft[space]2
It worked fine when I used the command prompt. Just to be clear here's what I did in that case:
I made a separate folder named c:\Qtest and copied the map named h1b.bsp and your light.exe as well as the related .pts file just in case that was an issue (the map itself doesn't leak but better safe than sorry right?) and ran light in the command prompt using:
CD: C:\Qtest
light.exe -extra4 -soft 2 h1b.bsp
on it and it worked just fine.
The map itself is very small with only a few entities, none of them outside of the vanilla Quake standard except for one (multiple brush item) func_detail that works just fine (that's why I was playing around with it in the first place) and a light that has "no falloff" selected in its properties.
Duh
#157 posted by quaketree [76.14.42.216] on 2013/03/17 14:15:51
I should add that [space] is just a space and not actually entered as [space].
Batch File
#158 posted by mechtech [65.190.158.200] on 2013/03/17 14:51:42
I just got things working in the cmd window and made a batch file. I find it easier than using the hammer compile setup.
An interesting thing I found today. Works on win7 with multi core cpu.
c:\windows\system32\cmd.exe /C start /affinity 1 yourbatfile.bat
Uses processor 0
c:\windows\system32\cmd.exe /C start /affinity 2 hammer.exe
Uses processor 1
Could be used to build your map on one cpu and hammer on the other. You could compile and use hammer without making it too slow.
Just an idea
#159 posted by necros [99.227.223.212] on 2013/03/17 17:07:39
that's cool, i usually just go into the task manager and remove a checkbox on one of the cores.
i should build something like this into the compiling gui.
#160 posted by Willem [108.228.244.211] on 2013/03/17 18:28:19
You could also right click the VIS process and set it to a lower priority. That way when you're using Hammer, it will fade into the background and when you're not it will get Windows full attention.
Or it should work that way, anyway.
#161 posted by necros [99.227.223.212] on 2013/03/17 18:46:06
yeah, I do that too. :)
That's actually better because windows will manage the priority itself so when you aren't doing anything it's using closer to 100% instead of ignoring a core completely.
Priority
#162 posted by Tyrann [203.122.220.108] on 2013/03/17 21:28:48
I could make vis set it's worker threads priority to low by default.
@quaketree: the problem seems to be with Hammer launching the light utility, not the light utility itself. If I get time I'll try set up Hammer here myself to see what's going on.
#163 posted by quaketree [76.14.42.216] on 2013/03/17 22:43:30
That's what I kinda figured, I only mentioned it here so that you could put that into your light readme as a known issue with Hammer and those extra -commands if you wanted to.
#164 posted by Willem [108.228.244.211] on 2013/03/18 10:47:54
Just go to "Below Normal". I think if you go to "Low" it starts to only get processing when there's NOTHING else to do, like OS or anything...
Feature Request...
#165 posted by FifthElephant [82.12.230.210] on 2013/03/23 13:24:36
I haven't had chance to look at the clip entity snapshot, sorry Tyrann (I solved it by messing around with brush shapes, ironically I might not even need it now since I have expanded my idea).
Anyway, is there any way of getting water to not be fullbright? Is it possible to get them to accept light and shadow?
This Goes For...
#166 posted by FifthElephant [82.12.230.210] on 2013/03/23 13:25:15
slime and lava too... maybe lava should always be fullbright, but then why not just use _minlight to achieve this?
*liquids
#167 posted by quaketree [76.14.42.216] on 2013/03/23 17:07:03
I believe (and someone correct me if I'm wrong) that they are handled by the engine and not the compiling tools as far as fullbrights are concerned. The only thing that gets done by compilers is to create a vis\bsp portal (not unlike a hint brush) unless you use -wateralpha (or whatever that command is in some qbsp programs) to make it transparent which simply removes the portal and in some cases takes away the fullbright.
(-transwater)
#168 posted by Scampie [72.12.65.92] on 2013/03/23 17:58:03
what quaketree said. engine is responsible for the 'lighting' of water (and sky).
Btw
#169 posted by necros [99.227.223.212] on 2013/03/23 18:15:09
Tyrann: you are awesome.
just in case you didn't know.
Cheers For The Info!
#170 posted by FifthElephant [82.12.230.210] on 2013/03/23 20:15:24
Doesn't -transwater affect performance?
Yes
#171 posted by negke [31.18.175.98] on 2013/03/23 20:40:35
It does insofar as it makes the water surface not block visibility, so everything beneath it is being rendered whereas it would've been visblocked if compiled with opaque water. Depends on how much additional detail there is underwater.
Lighting Water, Lava, Etc.
#172 posted by Tyrann [203.122.220.108] on 2013/03/23 23:27:51
Hmmm, it may just work - it looks like the software engine might actually render the lightmaps if the light util generated them. Not sure about glquake. Surface subdivision might cause problems. I'll try an experiment.
#173 posted by Tyrann [203.122.220.108] on 2013/03/24 00:05:51
Yeah, it appears it can't be done with tools changes alone. Oh well.
...
#174 posted by FifthElephant [82.12.230.210] on 2013/03/24 00:20:05
Cheers for looking into it! I still haven't checked out the latest snapshot... probably will do for the next map since everything is stable and I'm close to finishing...
Too Bad.
#175 posted by quaketree [76.14.42.216] on 2013/03/24 01:26:55
Tyrann, do you think that it's possible to make a *liquid do what a sky can do in regards to sunlight only upwards instead? Particularly ones that start off with *slime and *lava? At least then it would make some visual sense that they are fullbright. Obviously they would need .lit support and wouldn't be on by default. Maybe put it in the worldspawn. _mangle support might be nice if someone wants to do something funky in their maps. Just a thought.
Lava Light
#176 posted by Tyrann [203.122.220.108] on 2013/03/24 01:37:59
Yeah, I've been thinking about making it possible to set a global lighting level to emit a glow from lava/slime/water surfaces - separate values for each type though. Wouldn't be directed via mangle, but using sample points along the liquid surface.
Shouldn't be too hard but would want to make sure of consistent light levels above and below the water and will need to see how much performace impact it has.
Peachy
#177 posted by quaketree [76.14.42.216] on 2013/03/24 02:15:33
No mangle is fine, I was just thinking that someone might find some uses for that somewhere down the line is all. Thanks for the answer.
Tyrann
#178 posted by than [182.164.57.115] on 2013/03/24 14:07:02
Maybe you could allow users to set up a file called surfacelights.txt or something that contains a list of textures that should emit light? Maybe it could be defined in a worldspawn key? In addition, having separate support for _lavalight etc. in the worldspawn would be cool. It gets a bit messy if you want to support multiple textures and use different colours, attenuation formula etc. Perhaps it could be set up in a text file?
Rad
#179 posted by mechtech [65.190.158.200] on 2013/03/24 15:38:46
I had used Q1rad worked well, the effect was cool, then it broke when the map got large. Maybe light emitting textures could be done with a separate util then appended to the light map. Keep the light program on target without adding more complexity to it.
My ability to write code is limited to cut and paste so ignore me as needed.
-noambient
#180 posted by FifthElephant [82.12.230.210] on 2013/03/27 22:22:54
The version of the tools I'm using doesn't support -noambient to disable sounds applied automatically to skyboxes/water volumes etc... I've resorted to using the vis compiler that is coupled with quake adapter worldcraft. Is there a commandline option I am missing on your version?
Ambients
#181 posted by Tyrann [130.220.150.44] on 2013/03/27 23:04:23
Yeah, had it on my todo list but had not gotten around to it yet. You can be my beta tester!
tyrutils-0.6-46-g9c8cbfd-win32.zip
Brush Entity Shadowing..
#182 posted by FifthElephant [82.12.230.210] on 2013/03/27 23:38:44
Not sure this is always desirable. Is there a way to turn off shadow casting for brush entities? It may seem like a weird request but I have a moving platform on top of a kind of cylinder and I don't want the mover to cast a shadow under it. BTW, I've made good usage of _minlight for brush entities, it's a nice addition :)
Also..
#183 posted by FifthElephant [82.12.230.210] on 2013/03/27 23:39:49
the vis I'm using has options for -noambient, -noambientslime, -noambientlava etc etc.
FifthElephant
#184 posted by Tyrann [130.220.150.44] on 2013/03/27 23:56:12
Brush model shadows should be off by default - they should only cast a shadow if you have added the "_shadow" key.
Those noambient options are what I just added to vis in the snapshot linked above.
Ah Ok
#185 posted by FifthElephant [82.12.230.210] on 2013/03/28 01:27:08
I did open the file and only look at the changelog, not the main text :P
Ok
#186 posted by FifthElephant [82.12.230.210] on 2013/03/28 15:57:32
I've had a look at it. The -noambient switches work, but I get CutNodePortals_r: New portal was clipped away messages now that weren't there with TreeQBSP, also it's now saying I have a leak again even though I had fixed all my leaks in TreeQ. Could do with a -noents option so that I can use pointfile to find whatever is causing the problem (the pointfile particles are all outside the map again, grrr!)
#187 posted by Tyrann [203.122.220.108] on 2013/03/28 22:21:47
Try adding -particles 1000000 to the quake engine command line just in case you're running out of particles for the pointfile.
Tyr
#188 posted by FifthElephant [82.12.230.210] on 2013/03/28 22:35:13
It's not that, it happened with the previous version too. It just displays a line of particles completely outside the map.
When I used TreeQ with -noents it pointed to all the holes in the BSP before it pointed to the outside entities. I'm probably going to stop farting around with different compilers for this map now otherwise I'm never going to get it finished :P
(I have like 3 other maps I have started and need to get done too)
#189 posted by Tyrann [203.122.220.108] on 2013/03/28 22:49:07
Ah, ok - I thought you meant it was not pointing at an entity at all. I'll look at adding that option.
#190 posted by metlslime [159.153.4.50] on 2013/03/28 23:42:20
When I used TreeQ with -noents it pointed to all the holes in the BSP before it pointed to the outside entities.
Having entities that are accessible to the void is the definition of a leak. So you should probably not have entities outside the map (brush entities are okay, point entities are the problem)
Metl
#191 posted by FifthElephant [82.12.230.210] on 2013/03/28 23:49:52
The point is that I can't verify if it's a bsp leak *or* a void entity if I can't -noents, besides TreeQ and vis aren't signalling problems, just Tyr's latest version. It's all a bit weird to say the least.
Kind of having a problem with degenerating brushes for my terrain too, it's really odd. I'm losing interest in the map now, need to get it working as best as I can so I can move on.
This Might Be A Result
#192 posted by SleepwalkR [85.178.59.57] on 2013/03/29 00:16:35
of using double precision floating point numbers in Tyrann's tools. It snaps vertices to integer coordinates if they are off by less than 0.0001, whereas TreeQ snaps them if they are off by less than 0.001. So if you have two vertices which are off by, say, 0.0005, they will be snapped to the same position by TreeQ, but not by Tyrann's tools. The result could be a microleak I think.
You're Obsessed..
#193 posted by FifthElephant [82.12.230.210] on 2013/03/29 00:48:38
with microleaks! ;)
I'm using TreeQ atm and I'm still getting weirdness. It's probably due to me using cubes rather than triangles for this tri-soup business. Honestly I'm fairly clueless, but the map seems to be holding up ok... just hope people don't laugh too much at me when I release the .map file!
If You Send Me The File
#194 posted by SleepwalkR [85.178.59.57] on 2013/03/29 07:15:55
and indicate which brushes (line numbers) cause problems Incan probably give you a hint on what is going on exactly.
Oh,
#195 posted by FifthElephant [82.12.230.210] on 2013/03/29 11:02:49
I know exactly where the weird brushes are in the current iteration of the map, but it's stable and vising properly (except if you noclip to the bottom there are tiny little rooms between the brushes).
Honestly it's just the way I've done the terrain. I'm not redoing the whole thing a third time as triangles now, it would probably drive me to murder. I thought of another possible way of doing the terrain just as I went to sleep last night but again I just want to get the map out as long as it vis's right now.
I'm Not Asking You To Redo It
#196 posted by SleepwalkR [85.178.59.57] on 2013/03/29 11:21:42
But it would still be useful for me to see where what TB shows you differs from what QBSP will produce.
Sent
#197 posted by FifthElephant [82.12.230.210] on 2013/03/29 11:36:37
you an email with the file with an explanation.
#198 posted by slapmap [78.37.161.134] on 2013/04/02 20:03:00
On one map world brushes dont showing up (if they are compiled at all, not sure)- only funcs show up;
other compilers (txqbsp, hmap) compile same map fine.
Func_detail usage creates pretty much broken PVS.
Made in Netradiant.
Brushes Disappearing
#199 posted by slapmap [78.37.161.134] on 2013/04/02 20:23:17
confirmed: happens when you move brushes between ents involving func_group, moving back to world doesnt help - they still dont get compiled, but moving to other funcs makes them appear.
As said, other compiler do fine
netradiant
...
#200 posted by slapmap [78.37.161.134] on 2013/04/02 21:08:36
and probably cause netradiant leaves empty brush ents in .map
"classname" "func_group"
}
// entity 230
{
#201 posted by Tyrann [203.122.220.108] on 2013/04/03 02:04:14
@slapmap: Weird. Can you send me a .map which shows the problem?
Addmin
#202 posted by than [182.164.57.115] on 2013/04/03 13:15:16
This is something in bjp tools that I always used. Your light says it is not supported, though the lighting doesn't seem very different.
Also, I had an error about a missing face if I used light after newskip, but not when I used bjp light. Does your bsp support skip now, because if it does, I guess I can probably just switch. I'll probably want it for detail brushes anyway :)
_selfshadow and _shadow are awesome though! Thanks!
Tyrann
#203 posted by slapmap [178.70.193.219] on 2013/04/03 14:14:18
sent
#204 posted by Tyrann [203.122.220.108] on 2013/04/04 02:07:36
@slapmap: Thanks for the test maps. Should be fixed now - try the new snapshot
@than: Yeah, my qbsp supports skip but I only just looked at newskip now and realised that it has water/slime/lava skip as well. That shouldn't be too hard to add. Will look at what is going on with lighting newskip'd maps...
-addmin
#205 posted by Tyrann [203.122.220.108] on 2013/04/04 07:35:32
@than: does this give the expected results?
tyrutils-0.6-52-g4625245-win32
It's not 100% identical to the bjp tools when it comes to treatment of "local minlights", but it should otherwise just make minlights additive.
Tyrann
#206 posted by than [182.164.57.115] on 2013/04/04 17:34:45
thanks for that. I'll try to test it as soon as I can.
Anglescale
#207 posted by slapmap [78.37.177.189] on 2013/04/05 23:02:30
I tried -anglescale (and -anglesense) 0.01 and 0.99 and sunlit area looks identical. Shouldn't it be dimmer with higher value or faces hit at non 90deg?
#208 posted by Tyrann [203.122.220.108] on 2013/04/06 00:10:12
@slapmap: oops, missed setting the sunlight variable from the command line. This should fix it:
tyrutils-0.6-53-gee2dc38-win32.zip
-gate N
#209 posted by Scampie [72.12.65.92] on 2013/04/06 02:22:28
does this actually work? I was experimenting the other day with setting it to really high amounts to see the effect... and even at "-gate 100", there is nothing apparent. My assumption would be that this would make the map very dark with harsh cutoffs. Am I confused on how this works? (I understand that it's intended to be used with very low settings)
Using the released 0.6 tools.
-gate
#210 posted by Tyrann [203.122.220.108] on 2013/04/06 04:46:18
should work - only affect 1/x, 1/x^2 lights though. Doesn't affect lights with the default linear falloff.
#211 posted by Tyrann [203.122.220.108] on 2013/04/06 04:57:29
Updated to affect linear lights as well in the next release (which I should do soon).
#212 posted by Tyrann [203.122.220.108] on 2013/04/06 04:57:30
Updated to affect linear lights as well in the next release (which I should do soon).
#213 posted by [78.37.177.189] on 2013/04/06 14:38:53
Hmm, I still get no visible difference, even took screenshots - nothing. Sunlight is even no matter what value I use http://imgur.com/4GNXAzC
I use "light -anglescale 0.xx mapname.map"
to compile.
Again, thanks for quick updates
#214 posted by Tyrann [203.122.220.108] on 2013/04/07 00:14:52
I get a clear difference here - what keys are in your worldspawn entity?
-anglescale 0.5 (default)
-anglescale 0.0
#215 posted by slapmap [178.70.213.83] on 2013/04/07 01:04:46
"light" "10"
"_sunlight" "110"
"_sun_mangle" "300 -65 0"
#216 posted by Tyrann [203.122.220.108] on 2013/04/07 03:47:38
@slapmap
Those keys look okay. Just check the light.exe output and make sure you're running version 0.6-53-gee2dc38. Otherwise, if you email the .map to me I'll try it here and see if I can tell what's going on.
Transwater And Vis
#217 posted by FifthElephant [82.12.230.210] on 2013/04/07 14:49:09
Would it be possible to have separate vis for water,slime and lava? This way you could have a controllable form of occlusion culling to help keep r_speeds low.
Would Need Engine Support?
#218 posted by than [182.164.57.115] on 2013/04/07 16:04:02
r_wateralpha applies to all fluids, so you'd need to have some engine cvar that applies only to water in order to use that properly, otherwise you'd get HOM effects on the lava and slime that were blocking vis if their surface transparency was using the wateralpha setting :/
TyrUtils V0.7
#219 posted by Tyrann [130.220.71.27] on 2013/04/10 07:44:47
Nothing too earth shattering if you've already been using the snapshots, but if you're still on v0.5 or v0.6, there are some nice worthwhile changes:
* Unix man page documentation for the main tools (qbsp, light, vis)
* HTML and text documentation is generated from the man page sources
* qbsp: added support for using WAD3 texture wads used by Hammer
* qbsp: include clip brushes when calculating bmodel bounding box
* qbsp: enable creation of clip-only bmodels
* qbsp: recognise and remove *waterskip, *slimeskip and *lavaskip surfaces
* qbsp: added hintskip texture support
* qbsp: fixed some bugs parsing empty func_group/func_detail entities
* light: implemented self shadowing and full shadows for brush models
* light: implemented the "-soft" command line option
* light: implemented the "-addmin" command line option
* light: implemented the "_anglescale" (aka "_anglesense") key and cmdline
* light: remove support for negative color components (never worked properly)
* light: removed the "-nominlimit" option (now the default behaviour)
* light: removed the "-compress" option (a bad idea from long ago)
* light: make -gate command line affect linear falloff lights as well
* vis: changed the default testlevel to 4
* vis: added the '-noambient*' options to disable auto ambient sounds.
Compile Errors
#220 posted by FifthElephant [82.12.230.210] on 2013/04/10 17:06:40
So I decided to have a look at using your tools for making my deck remake into a singleplayer level (along with using the new version of trenchbroom) and all I get is constant errors about leaks that weren't present when I used TreeQ to compile the map.
I've tried to fix verts and such but to no success, the pointfile doesn't point to any leaks...
#221 posted by Willem [199.255.42.114] on 2013/04/10 17:13:44
To save Tyrann some time, can you send him the MAP file so he can debug it? :)
..
#222 posted by FifthElephant [82.12.230.210] on 2013/04/10 17:25:46
Ok, I've forwarded the email that I sent to SleepwalkR as that contains the details. I've included the .map, the .log and the .pts file. Doesn't seem to point to anything with the confines of the map. Bear in mind that this fully compiles using TreeQ, I'm not sure why it doesn't compile with your new tools because I'm not so familiar with mapping for quake.
Tried Hammer
#223 posted by mechtech [65.190.158.200] on 2013/04/10 17:55:54
I loaded the .map included in the download in Hammer got 20 brushes that could not be loaded. the missing brushes cause leaks. Loads fine in Trenchbroom and compiles without leaks using Txqbsp.exe
Mechtech
#224 posted by SleepwalkR [130.149.243.224] on 2013/04/10 18:38:43
Did Hammer say anything about why those brushes could not be loaded?
Brush Line #
#225 posted by mechtech [65.190.158.200] on 2013/04/10 20:30:13
Hammer gives no usefull info
Any way to get the map line number from selected brush? I found the missing brushes but how to pass on the info.
Line#
#226 posted by mechtech [65.190.158.200] on 2013/04/10 20:43:31
Changed the texture in trenchbroom and saved. As long a brush order was not changed on save. brush starting at line# 15116-15127 and 15128-15139 are two that will not load in Hammer 3.4 build 2363
5th
#227 posted by Tyrann [130.220.71.24] on 2013/04/11 01:10:48
Thanks, looking at it now.
#228 posted by Tyrann [130.220.71.26] on 2013/04/11 02:33:34
Wow, this is an interesting one!
There are some odd plane definitions, just off the grid like this one:
( 55.9998779296875 103.99990844726562 -72 ) ( 80.00042724609375 128.00054931640625 -72 ) ( 55.9998779296875 103.99990844726562 -88 ) tech04_6 0 0 0 0.5 0.5
But the pointfile my qbsp is generating looks like complete garbage. Might take a while to work it out, but I think it's worth finding out exactly what is going on.
Yeah..
#229 posted by FifthElephant [82.12.230.210] on 2013/04/11 02:53:03
I only ever bring problems to the table, I'm kind of a jerk like that. But at least you have a complete maniac messing around with all these tools, should make for fun times!
Maybe
#230 posted by SleepwalkR [92.231.107.93] on 2013/04/11 07:17:26
TB should round the plane points if they're this close to integers. OTOH, the way the vertices are generated, small changes to plane points may yield big changes to vertex positions.
Can't Bsp A Map That Compiles Fine With Other Tools :/
#231 posted by than [182.164.57.115] on 2013/04/17 14:19:04
Getting this error:
---- GrowRegions ----
*** ERROR 43: Internal error: entity->iVertices > entity->cVertices
I'll mail you the map if that's ok? It's made in Worldcraft by the way.
Light Not Working For Me
#232 posted by mechtech [65.190.158.200] on 2013/04/17 14:49:31
---- light / TyrUtils v0.7 ----
running with 2 threads
BSP is version 29
using minlight value 40 from worldspawn.
Colored light entities detected: .lit output enabled.
************ ERROR ************
LoadEntities: MAX_MAP_ENTITIES
BSP built with version 0.7
Same map will light with mhlight.exe
Error 43: Entity->iVertices > Entity->cVertices
#233 posted by Stahlkralle [195.39.235.27] on 2013/04/17 17:56:32
@than:
had this error too.
was skip texture on some surfaces of clipped or vertex edited brush entity.
Probably
#234 posted by than [182.164.57.115] on 2013/04/18 02:11:11
somewhere in the map, given the number of clipped or vetex edited brushes in it. I don't see why that would cause a problem though :/
Are you also using Worldcraft 1.6a? I didn't think anyone but me used it these days (I think most people use 3d accelerated 3.3)
#235 posted by Tyrann [130.220.71.27] on 2013/04/18 02:26:08
@than, @Stahlkralle, @mechtech
Thanks for the bug reports guys. Both issues should be fixed now - please try the new snapshot and let me know if that's fixed it.
Thank You
#236 posted by mechtech [65.190.158.200] on 2013/04/18 03:02:47
Map compiles fine now!!!
The func_detail thing is working great. Like getting a new CPU. vis is no longer the enemy.
No Luck :(
#237 posted by than [182.164.57.115] on 2013/04/18 04:32:33
---- GrowRegions ----
35%---- light / TyrUtils v0.7 ----
extra 4x4 sampling enabled
GrowRegions breaks with no error at 35% and then light won't run because there is no bsp :/
Did you manage to get my map to compile? If so, maybe there is some problem with the current version. It's currently under all limits and is compiling fine with aguirre's qbsp though.
#238 posted by Tyrann [130.220.71.24] on 2013/04/18 05:07:49
@than: yes it compiled here, although without textures - I'll try to work out which wads I need, but feel free to just email them to me if that's easy enough.
Slimeskip
#239 posted by mechtech [65.190.158.200] on 2013/04/18 05:08:09
Causes HOM. Works like slime but does the HOM like a worldbrush with skip texture.
Using snapshot from post #235
Oh, Wait
#240 posted by Tyrann [130.220.71.27] on 2013/04/18 05:34:29
I'm a dummy and messed up the test map. This time for sure, Rocky!
tyrutils-0.7-10-g7e6474c-win32.zip
#241 posted by Tyrann [130.220.71.27] on 2013/04/18 05:36:55
@mechtech: that's expected unless you compiled with -transwater so that liquids don't block visibility.
RTFM
#242 posted by mechtech [65.190.158.200] on 2013/04/19 03:57:22
Tyrann my mistake. -transwater did it.
Thanks
-transwater
#243 posted by mechtech [65.190.158.200] on 2013/04/19 04:52:23
Using -transwater switch causes vis to crash. No errors reported by the program. I get the windows crash warning. Then it goes on to light. Map will run. I emailed the map and wad.
Than, Mechtech
#244 posted by Tyrann [130.220.150.44] on 2013/04/19 05:20:00
Thanks guys - there does appear to be a problem with the skip support at the moment. As a workaround, I've added a "-noskip" option to the latest snapshot so you can use that and then run the extra "newskip" tool afterwards.
I'll try to get to the bottom of it this weekend and get a proper fix in there.
Thanks!
#245 posted by than [182.164.57.115] on 2013/04/19 12:32:55
I'll give that a whirl
Skip Fixed, Vis Crash Fixed
#246 posted by Tyrann [203.122.220.108] on 2013/04/21 03:03:51
@than, @mechtech:
Please give this snapshot a try - both your maps are compiling for me now.
There are still some interesting HOMs in mechtech's map which I'd like to try and solve before I do a new release, but they don't seem to be related to skip at all.
Snapshot
#247 posted by mechtech [65.190.158.200] on 2013/04/21 05:45:31
Compiles, no vis crash, HOM is odd. I removed func_detail and compiled with Txqbsp, newskip, WVis and mhlight just to make sure I hadn't screwed up the map. Compiled without error and no HOM.
HOM Fixed
#248 posted by Tyrann [203.122.220.108] on 2013/04/21 06:10:56
As I thought, the HOM was my fault - qbsp bug.
This new snapshot should hopefully be bug free! I'll do a release if this one looks okay. Thanks again for testing!
Hahaha
#249 posted by SleepwalkR [92.231.233.44] on 2013/04/21 08:46:58
This new snapshot should hopefully be bug free!
You jinxed it! ;-)
No HOM
#250 posted by mechtech [65.190.158.200] on 2013/04/21 15:31:59
I compiled with the new snapshot. HOM is gone. I expanded the use of func_detail in the map. I haven't found any bugs yet, I'll keep trying to break things.
I do have an idea that might be useful for beta testing. Could a command line switch be setup to cause func_detail to use a specific texture. I could then run through a map and see better what can be optimized.
example
http://www.quaketastic.com/upload/...
http://www.quaketastic.com/upload/...
Is That A Q1SP Of Yours?
#251 posted by RickyT23 [2.124.172.55] on 2013/04/21 16:17:15
If so:
WO_OT?!?
That looks sweet as furk.
Ricky
#252 posted by mechtech [65.190.158.200] on 2013/04/21 17:03:14
That was an experiment I did with the texture set from Sock's website. Made some models with Gmax, hacked up a few I found on the internet to reduce poly count. At the time all it could ever be was one room. Vis time was prohibitive, so the map is unvised.
Then TyrUtils showed up. In the second shot you can see what I turned into func_detail. Vis treats it as just a box. Vis in under 2 minutes!!!
The unvised version with texures and sound is here http://www.mediafire.com/download....
Use Fitz V it has hi rez skins.
Pointfile
#253 posted by mechtech [65.190.158.200] on 2013/04/22 01:19:40
Broke something :)
Latest snapshot does not generate a correct pointfile. In Hammer pointfile shows up well outside the map grid.
What Is Causing
#254 posted by slapmap [178.70.222.143] on 2013/04/22 02:59:46
light / TyrUtils v0.6
0....1....2....3....4....5....6...... ERROR ************
\
LightThread: no model has face 8213
0....1.
Get The Latest
#255 posted by mechtech [65.190.158.200] on 2013/04/22 03:30:10
Get the files on post #248
I got that error when using newskip.exe
Latest version does skip removal.
No Model Has Face...
#256 posted by Tyrann [130.220.150.44] on 2013/04/22 05:23:51
The external skip tool will cause that. I should probably reduce that to a warning and skip to the next face.
Mechtech
#257 posted by Tyrann [130.220.150.44] on 2013/04/23 02:03:56
Looked into the detail re-texturing thing a bit this morning and it's a little tricky due to the order in which qbsp currently sets up the textures/texinfo/etc. But it's a cool idea and I'll keep it on the todo list for later.
Those screenshots look awesome by the way.
TyrUtils V0.8
#258 posted by Tyrann [130.220.150.44] on 2013/04/23 02:41:36
No major new features, but some important bug fixes since 0.7:
* qbsp: fixed surface edge corruption when using skip surfaces
* qbsp: fixed portal generation for transparent water and detail nodes
* qbsp: added "-noskip" option for troubleshooting skip related problems
* light: reduce "no model has face ###" to a warning
* vis: fix portal stack corruption in ClipStackWinding
* bsputil: added a "--check" option (beta!) to check internal data consistency
#259 posted by mechtech [65.190.158.200] on 2013/04/23 03:13:40
nt
TyrUtils V0.8
#260 posted by Tyrann [130.220.150.44] on 2013/04/23 03:36:02
Forgot to add a download link!
http://disenchant.net/utils/
Tyrann You Rock
#261 posted by slapmap [178.70.222.105] on 2013/04/23 05:09:26
dalay 4 -addmin = realism achieved, no need for radiocity!
I'm actually very happy now, for the first time I got truly good lighting out of q1 compilers. And better than from q-rad. No more dull flat outdoors!
Slapmap
#262 posted by than [221.244.26.90] on 2013/04/23 06:55:01
would be nice to see a picture of what kind of lighting you achieved with the delay 4 setting.
I always use addmin, but usually try and eliminate minlight for the final map, adding as much fake ambient as possible via fake bounce lights placed in the map. This is basically lights with low intensity and long falloff placed near highly lit surfaces to simulate light being reflected off the surface. I think it works quite nicely, but it's a bit of a hassle to set up, so some kind of automatic way to do it (or even real radiosity ;) ;) ;) ) would be a great help.
Yeah
#263 posted by RickyT23 [86.160.144.189] on 2013/04/23 10:38:40
Comparitive screenshots please!
Fake GI
#264 posted by slapmap [178.70.222.105] on 2013/04/23 18:38:26
Using many small local minlights spaced around the sky flat
same with -addmin: sexy
I wrote a detailed post /tutorial explaining with some more pics.
I thought delay 3 would be the same, but it works differently, can Tyrann explain why?
Good Tutorial
#265 posted by FifthElephant [82.12.230.210] on 2013/04/23 18:51:45
and the results are really nice too.
Yeah
#266 posted by ijed [200.73.66.2] on 2013/04/23 19:43:57
Never occurred to me to try that. Thanks!
Also reminds me of the antilights feature...
Nice Pics
#267 posted by than [182.164.57.115] on 2013/04/23 22:45:25
You can still see that you have used multiple light sources because there are some extra shadows, but overall it looks pretty good. Your blog has some nice map pics too - looking forward to seeing what you are working on!
Your geometry is interesting btw, did you work on some other game(s) before doing Q1 mapping?
Its Pure Math
#268 posted by mfx [78.55.250.16] on 2013/04/24 00:42:50
thank you slapmap!
TyrUtils V0.9
#269 posted by Tyrann [130.220.150.44] on 2013/04/24 01:58:11
Thought it was worth a new release just to fix this silly bug with point files being incorrect.
2013-04-24 TyrUtils v0.9
* qbsp: fixed bad pointfile generation
Download from disenchant.net.
Delay 3/4 Difference
#270 posted by Tyrann [130.220.150.44] on 2013/04/24 02:01:26
Both delay 3 and delay 4 have no light falloff with distance, but delay 3 brightness is affected by the angle at which the light hits the surface whereas delay 4 has the same brightness at any angle of incidence.
Quick Question Re Detail
#271 posted by than [221.244.26.90] on 2013/04/24 02:27:27
Does detail just mean they don't create new portals but can still block visibility?
#272 posted by Tyrann [130.220.150.44] on 2013/04/24 02:39:47
Detail brushes don't create portals and don't block visibility.
Thanks For The Update
#273 posted by mechtech [65.190.158.200] on 2013/04/24 03:23:38
HOM Again
#274 posted by mechtech [65.190.158.200] on 2013/04/24 03:36:59
Ver .9 creates a HOM that is not present in ver .8
Do you want the map?
Mechtech
#275 posted by Tyrann [130.220.71.27] on 2013/04/24 04:03:40
Yes please, send it through. Not seeing any HOMs in the one you sent earlier. Cheers dude.
Some Small Problems
#276 posted by than [182.164.57.115] on 2013/04/24 13:53:21
I think (not sure...) that using animating textures on detail brushes causes the compiler to miss out adding the texture to the bsp. I have just been doing some detail stuff on my map, and it seems to do the trick with regard to the compile times, but now I have a missing texture error on map load, which causes FQ to crash :(
Also, I started trying to play with hint and hintskip and am getting some warnings:
WARNING 09: Couldn't create brush face. I will mess around with that and see if I can fix it by recreating the hint brushes and send you the map if I can't.
Map Sent
#277 posted by mechtech [65.190.158.200] on 2013/04/24 15:44:56
Hmm
#278 posted by than [182.164.57.115] on 2013/04/24 16:12:21
seems it wasn't the hints, since I removed them anyway.
I also had a few glaring HOM bugs too. Will investigate further soon. Very tired right now so going to bed.
Sorry
#279 posted by than [182.164.57.115] on 2013/04/24 16:20:50
it was the hint brushes. I will experiment with them later.
The HOM bugs are extremely severe - this is happening in a bare bones version of the map with only the world brushes (no detail), the player start and light on level 4 vis.
vis runs well fast though ;)
#280 posted by slapmap [178.70.206.162] on 2013/04/24 16:40:51
than: Yes, there are secondary shadows which can be reduced using more (but smaller value) ambient lights.
I rather get inspiration from interesting concept art and architecture.
Tyrann: Ah, thats why delay 4 lights produce smoother and brighter result.
And what is delay 5 formula? It's very bleak, have to make light value 100+ to make it noticeable. Cant figure what its useful for.
Isn't That
#281 posted by ijed [200.73.66.2] on 2013/04/24 20:03:03
Antilight?
If So
#282 posted by ijed [200.73.66.2] on 2013/04/24 20:06:08
Could it be used to create shadows in a minlight 1000 scene 0_o
TyrUtils V0.10
#283 posted by Tyrann [203.122.220.108] on 2013/04/25 01:05:18
Sorry guys, there was a pretty glaring bug there with the vis util - let me know how you go with the hint brushes as well, since I've only made simple tests for those so far.
2013-04-25 TyrUtils v0.10
* Documentation added for bspinfo and bsputil
* Fix vis bug due to missing vertex copy in v0.9 portal clip changes
Download from disenchant.net.
HOM Bug Gone!
#284 posted by than [182.164.57.115] on 2013/04/25 01:24:29
Thanks, Tyrann!
HOM Dead
#285 posted by mechtech [65.190.158.200] on 2013/04/25 03:59:45
Thank you for the fast update.
HOM
#286 posted by quaketree [76.14.42.216] on 2013/04/25 04:14:58
Yeah, I had a small issue when looking at a func_wall through a skip brush that went away with this update. Thanks Tyrann.
Map Leaks...
#287 posted by FifthElephant [82.12.230.210] on 2013/04/25 21:13:51
in pretty much all versions. I've been using TreeQ because it doesn't seem to find invisible leaks, I've decided to try and move over to something with more features and I'm getting invisible leaks again.
Oh..
#288 posted by FifthElephant [82.12.230.210] on 2013/04/25 21:14:29
I moved to version 10 simply because the pointfile has been fixed, and it's pointing to something that doesn't have a hole in it.
Managed To...
#289 posted by FifthElephant [82.12.230.210] on 2013/04/25 22:07:24
get it to compile after chopping out a bunch of brushes... honestly though they don't look screwed up to me at all. They all look grid snapped and valid.
Fifth
#290 posted by SleepwalkR [85.178.118.200] on 2013/04/25 22:23:47
Send me the map file with the invalid brushes please - I can't fix these problems without test cases!
SW
#291 posted by FifthElephant [82.12.230.210] on 2013/04/25 22:33:47
I'm doing it now buddy chillax!... :P
Qbsp Crash...
#292 posted by FifthElephant [82.12.230.210] on 2013/04/26 00:58:12
I have a version of my speedmap that hard-crashes the qbsp program in the latest build... (yeah it's that buggy as shit speedmap that I pretty much abandoned in a fit of rage)
Heh
#293 posted by Tyrann [203.122.220.108] on 2013/04/26 05:03:41
@Fifth: It might be a buggy map, but still interesting to see - I don't want qbsp to crash at all. Send it through if you don't mind.
FifthElephant
#294 posted by slapmap [78.37.161.104] on 2013/04/26 14:32:21
I had leaks and collision "holes" on my grid-aligned terrain as well, it often happens with complex non-axial geometry like terrain, because qbsp creates many usless splits everywhere from adjacent planes. Sometimes its just random and you can move geometry around and it becomes better (or worse).
Turn on r_showtris and marvel at the mess of q1bsp.
Is it even possible to make compilers stop splitting everything with everything and keep the original editor geometry, like q3map does, but still maintain q1bsp format compatibility? Why even brush_ents have splits inside an entity. Its already bad enough that splits are every 255 units just for compatibility with 90s software render. Ridiculously inefficient.
Slap
#295 posted by FifthElephant [82.12.230.210] on 2013/04/26 15:05:34
To be honest in that speedmap I had messed around with a few settings in the hope that I wouldn't have to change my method of making terrain (which is somewhat similar to floor lofter method in UT)... it was pure laziness on my part.
Regards to the earlier invisible leaks it was some other bug in a different map (non-terrain).
I do want to make more interesting terrain but it looks like I'll have to make compromises if it's for Quake 1. Even making non-collision geometry and trying to make my own clipping using clip brushes seems to bring its own problems.
Even worse is that Q3 is probably a good game to make maps for in terms of stability and compatibility but it's a multiplayer game, who cares about that? It's good if you want to make a portfolio of work, but if you want to make a fun map to play then you'd get a bigger audience mapping for Doom 1 or 2.
Tyrann
#296 posted by necros [142.245.59.16] on 2013/04/26 15:11:37
would it be possible to add in a mode where sunlight is replaced with an array of suns shining at different angles in a sphere? would be a nicer, more consistent (and easier) way of doing fake GI.
the sun array needs to be additive, but the values would need to add up to the final value specified as the sun level, so you'd probably need to make the individual suns in the array emit at maybe 1 or 2 brightness, which means you'd need floating point light values up until you right the results into the map file, at which point it would be safe to round them off.
#297 posted by Tyrann [203.122.220.108] on 2013/04/27 01:45:48
@necros: Sure it's possible, but not sure how good it would look for a whole lot more ray traces per surface point. Will put it on the TODO list as something to try out though.
It Looks Like This
#298 posted by necros [99.227.215.224] on 2013/04/27 02:58:50
http://necros.fov120.com/temp/nesp...
Fake GI
Normal Sunlight
This is with 32 suns iirc.
Fake GI
#299 posted by metlslime [159.153.4.50] on 2013/04/27 03:03:29
I had modded light.exe to do this a long time ago, and it does look good. You need a lot of suns for best results, though.
FYI, the mod was really easy -- BJP's "skyambient" already exists and uses a multiple sun method, but gives really flat results, and all you need to do is remove the clamping and make the suns much dimmer (and more numerous) and you'll get something that looks like GI.
#300 posted by necros [99.227.215.224] on 2013/04/27 03:52:15
yeah, that's what i did for the above shots. i was hoping for some better integration from someone who knew what they were doing. :)
my version has a severe limitation because light levels are integer values but because of the number of suns, the actual light levels that those suns emit needs to be very low so you would need fractional values for all these low level suns. the end result would still be well over 1.0 so you'd just round the final result (after all the suns have been done, since they are done first) and then you would just light normally with the rest of the point lights.
#301 posted by Willem [108.228.244.211] on 2013/04/27 11:38:45
With a multithreaded light util the extra traces shouldn't matter. Light is never the bottleneck in map iteration anyway! Those tests look great, necros!
Don't...
#302 posted by FifthElephant [82.12.230.210] on 2013/04/28 14:17:02
ever apply clip textures to a func_detail... I just spent about 30 minutes tearing my hair out because of errors.
Clip W/func_detail
#303 posted by quaketree [76.14.42.216] on 2013/04/28 19:13:40
Use a Skip texture instead. That gives you an invisible (solid) brush that will cast shadows.
Reminder
#304 posted by Preach [77.98.165.95] on 2013/04/28 19:35:21
Remember that projectiles collide with skip brushes but not clip brushes, in case that matters to you. But yeah, if it's not possible to create a clip detail (which isn't a very sensible combination when you think about it) a warning from the compiler might be best.
Guiz Guiz....
#305 posted by FifthElephant [82.12.230.210] on 2013/04/28 19:41:27
I was being lazy when I was making the clip brush that's all... I have no idea what a clip detail brush would accomplish. :P
A Skip Textured Detail Brush
#306 posted by quaketree [76.14.42.216] on 2013/04/28 21:18:31
Can be used to make a shadow where there is no structure (perhaps as a hint to a secret area?) without having to mess with recessed areas behind a sky texture (as seen in e1m5 where there's a Quake symbol shadow leading to the Quad secret) and then using func_illusion to make a false sky. Seeing as the detail brushes will get merged into the bsp as brushes and not as an entity it helps to keep the entity count down as you don't need to have the func_illusion brush.
The tricky part would be putting it where it won't be noticed by the player because it will of course act like a wall in all respects (with the exception that it won't be drawn on the screen). So it would have to be high enough to not block the players movements and not block a monsters attack in normal circumstances.
Func_illusionary
#307 posted by mechtech [65.190.158.200] on 2013/04/28 22:14:39
You can use a func_illusionary with _shadow set to 1 and skip texture to make invisible shadow casting brushes without collision.
I Totally Did Not Know That
#308 posted by RickyT23 [86.145.251.165] on 2013/04/29 11:52:09
Really?
How About...
#309 posted by FifthElephant [82.12.230.210] on 2013/04/29 16:38:59
an invisible collision brush that doesn't cast a shadow?
Clip Texture
#310 posted by ijed [200.73.66.2] on 2013/04/29 17:31:29
Didn't know that about func_illusionary either.
-onlyents Bug?
#311 posted by than [180.146.53.39] on 2013/05/02 16:31:30
When you compile with onlyents, switable light styles seem to get broken. I remember this being a problem in older tools that aguirre fixed in his tools. Maybe you could check that one out, Tyrann?
Than:
#312 posted by metlslime [159.153.4.50] on 2013/05/02 22:33:28
you need to run light -onlyents after running qbsp -onlyents. This is true for the original tools as well, Ii think.
#313 posted by Tyrann [130.220.150.44] on 2013/05/03 00:36:56
I don't remember there being a -onlyents option on the original light. That might be what aguirre added as a fix. I'll take a look.
Metl
#314 posted by than [221.244.26.90] on 2013/05/03 06:15:49
-onlyents on light is only supported in aguirre's tools afaik, though for all I know, it maybe have been supported in the original tools. I always used tyrlight before switching over to aguirre's tools though (except for the time I used the WC1.6 compile dialogue... yuck!)
Than:
#315 posted by metlslime [69.181.117.43] on 2013/05/03 07:32:42
you might be right. I have been using aguirre's tools for a long time now, can't remember what the original tools did and didn't do.
#316 posted by necros [142.245.59.17] on 2013/05/03 18:52:21
yes, that's correct about onlyents on light. it was added to address the problem where doing onlyents with qbsp would break switchable lights.
Not Working For Me
#317 posted by Qmaster [50.40.228.68] on 2013/05/07 19:16:44
qbsp:
...
Opened WAD: \program files (x86)\worldcraft\textures\tech1.hl...
*** WARNING 15: \program files (x86)\worldcraft\textures\tech1.hl... isn't a wadfile
*** WARNING 01: No valid WAD filenames in worldmodel
And seriously???:
*** WARNING 06: No info_player_deathmatch entities in level
vis:
Seems okay. I love the resume feature.
light:
I'm getting a TestLineOrSky: tstack overflow
Bengt's light 1.43 gives me everything fine. Here's my light info:
454 entities read, 333 are lights, 40209 faces, 500M casts
Unless I'm missing some compile parameter, then I'm going to be sticking with ol' Jardrups light. The vis is wonderful though, thanks Tyrann!
Qmaster
#318 posted by Tyrann [130.220.71.24] on 2013/05/08 02:01:20
Not sure about the invalid wad file - can you email me a zipped copy?
Tstack is trivial to increase, will do that for the next release.
Qmaster
#319 posted by Tyrann [130.220.71.26] on 2013/05/08 02:09:56
Oh wait - TestLineOrSky has been removed for a while - make sure you're using the latest versions - http://disenchant.net/utils/
Tyrann
#320 posted by quaketree [76.14.42.216] on 2013/05/08 09:28:27
Does your light compiler support _sunlight2? If not is it possible to add that?
Latest Version?
#321 posted by Qmaster [50.40.225.215] on 2013/05/08 17:42:58
The only version available on your website is 0.10. I have version 0.6 which is posted at the top of this forum. And sorry, I didn't realize that the wad name was cut off. They are .hlwad's since I'm using Worldcraft 3.3 with the quake patch. It's just the standard quake wads converted to hlwad...well with my own additions and modifications that is, scavenged from various places.
What version is the latest? and does it support hlwad setups?
More Fun With Func_detail
#322 posted by mechtech [65.190.158.200] on 2013/05/08 18:02:19
After applying func_detail to brushes in my map I noticed with r_showtris that areas behind were showing up. The detail brushes were allowing vis to see through the brushes that intersect the func_detail. I found func_detail cannot be used like func_wall where you block the back and your good. The solution I found was a small void gap between areas.
Qmaster: Version .10 supports hl wad files and format 220 valve maps. Use Utils hompage link above.
Tyrann: the download link points to old version .6
Hlwad
#323 posted by FifthElephant [82.12.230.210] on 2013/05/08 18:02:32
is actually just a wad3 .wad. AFAIK you cannot load this into TB. So either convert them to normal .wad using TexMex or download the .wad from somewhere (I suggest quaddicted's ftp).
Versions Confusion, So...
#324 posted by Qmaster [50.40.225.215] on 2013/05/08 18:24:52
Version 0.10 is greater than version 0.60? Is this 0.6 + (4 * 0.1) = 0.1 ?? Version maths, what can you do *shrug*. Anyways, thanks, will try.
@FifthElephant: Gotcha, thanks!
Math Go Figure Logic No Way
#325 posted by mechtech [65.190.158.200] on 2013/05/08 18:28:28
Qbsp Still Doesn't Want To Play Nice.
#326 posted by Qmaster [50.40.225.215] on 2013/05/08 18:40:04
Using version 10 now :)
....hlwads load good...
CSG... everything fine
6183 brushes
35535 brushfaces
yadda yadda
---- SolidBSP ----
1...37 38 39 40 41 42 43 44 45 46*********** ERROR ************
Mixed face contents in leafnode near (140.00 40.00 0.00)
no bsp made
This mix point (140, 40 ,0) is a corner where 4 brushes meet. The two walls tjunc. The floor tjuncs with the walls. And a lava brush tjuncs with everyone else. And then qbsp gives me this juncky error. I don't get it, compiles fine in txqbsp. I'll see if I can reproduce it with just those brushes in a dummy map.
Light Works In Version 10 Btw
#327 posted by Qmaster [50.40.225.215] on 2013/05/08 18:43:19
Ah
#328 posted by ijed [200.73.66.2] on 2013/05/08 18:43:59
I think that's not the junctions, just that you've got a sky brush touching a liquid brush.
Leave a gap between them, filled with regular brushwork if that'd cause a leak.
Qbsp Worked! But Only For 4 Brushes (inside Another Hollowed One)
#329 posted by Qmaster [50.40.225.215] on 2013/05/08 18:57:49
Well qbsp finally worked. Wierd output though.
Seems I'm getting 352% for SolidBSP with every other % in between. After 100% they all run together.
....
57 mergedfaces
---- SolidBSP ----
1 2 3...... 94 96 98100101103105107108
110...347 349 350 352 200 split nodes
71 solid leafs
...
I'm still psyched up about having new compile tools! This is great. Multithreaded vis was way faster than my old one. Even between versions Tyrann has made improvements. Version .10 vis was about 8 minutes faster than .6 on a map with 6000+ brushes...surrounded by a cheater's cube!! :P
Tyrann's lighting was also much faster than my old bengt modified light, less than half as much time. Hurray for multithreading!
Ijed
#330 posted by Qmaster [50.40.225.215] on 2013/05/08 19:09:57
Nearest sky brush is over 1000 units and several leafs away from that corner. But that's a good thought, you know I don't think I've ever tried bumping liquid up to sky before. huh.
Hrrmm... Still can't get tyr's qbsp to swallow this one map of mine. Granted, the map doesn encompass the ENTIRE grid in Worldcraft 3.3, but its only 16MB when compiled...so far.
Tried another smaller map. It worked FINE.
#331 posted by Tyrann [130.220.71.26] on 2013/05/09 01:22:51
@quaketree - no _sunlight2 support right now, but I'll add it.
@mechtech - I think you are seeing this effect (and it's normal - just fill in the cavity to remove the overdraw).
@Qmaster - Yeah it's not obvious, but the '.' in the version string is a separator, not a decimal point. The old treeqbsp progress counter is a bit whacky and will be getting replaced. Happy to take a look at the compile problem if you send me a .map and any wads I'll need to compile it.
I might make a discussion thread for the utils because we're not really talking about version 0.5 anymore :)
Here Tyrann...
#332 posted by Qmaster [50.40.225.215] on 2013/05/10 03:35:43
Tried it on another large map of mine.
I sent you an email with my .rmf and .map files and the log that qbsp spit out zipped up in city_src.zip
Tyrann
#333 posted by quaketree [76.14.42.216] on 2013/05/10 05:34:27
@quaketree - no _sunlight2 support right now, but I'll add it.
Spiffy. I'm guessing that adding features that other popular compilers already support can only boost the use of yours.
#334 posted by Tyrann [130.220.71.25] on 2013/05/10 06:39:08
@Qmaster: cheers, will take a look over the weekend.
What Would Be Really Cool Is...
#335 posted by Qmaster [50.40.227.248] on 2013/05/11 17:12:12
Qbsp support for displacement to brushes automatically with a command parameter of dispheight to set the thickness to automatically offset from a displacement surface's normal (negative normal that is) from hammer.
Oh and a command param to disable it such as
-nodisp
Hm
#336 posted by ijed [200.73.66.2] on 2013/05/15 17:46:43
Looks like I've got the same mixed face contents in leaf error.
The map is unsealed though, so will fill in the gaps first.
Comes under the same specifications as QMaster's map - the sky is nowhere near the brushes in question, although there is liquid there.
Ok, Got It
#337 posted by ijed [200.73.66.2] on 2013/05/17 01:16:25
The tools don't support non-rectangular liquid brushes. If used then they produce the 'mixed face contents in leaf node' error and don't build the bsp.
#338 posted by Tyrann [203.122.220.108] on 2013/05/17 11:39:26
That's pretty weird. Let me test that...
#339 posted by Tyrann [203.122.220.108] on 2013/05/17 11:45:30
Not just non-rectangular.
ijed: got a fairly simple test case which show the incorrect mixed face contents problem?
Sure, I Can Make One
#340 posted by ijed [200.73.66.2] on 2013/05/17 16:32:51
Will send it sometime today.
Sorry
#341 posted by ijed [200.73.66.2] on 2013/05/17 22:55:40
Looks like I won't have time today. I should be able to set up a few test maps easily enough Monday though.
Oh That Makes Sense..
#342 posted by Qmaster [50.40.240.99] on 2013/05/20 00:06:51
The small map I got to compile didn't have any liquid brushes.
The two larger maps I tried both gave errors on liquid brushes that were clipped at angles in the corners.
Wierd... I wonder what would have broken that support.
Oh And Also
#343 posted by Qmaster [50.40.240.99] on 2013/05/20 00:10:26
Rectangular liquid brushes that get tjunc-ed such that they result in more than 4 sides (square/rect) volumes don't work either, although it seems kind of random from my few trials. Hard to make out what is going on when there is such complicated geometry clipping with this one large liquid brush.
I'd look into it but I'm busy this weekend.
#344 posted by Tyrann [130.220.71.27] on 2013/05/20 06:00:23
No problem, I've had very little time for this the last couple of weeks anyway. Will be away this weekend too, hopefully back to normal later next week.
No Home PC
#345 posted by ijed [190.22.115.141] on 2013/05/20 13:23:39
For me.
Not sure if this has already been requested, but a few people have been experimenting with GI solutions recently, starting with slapmap.
I know you mentioned implementing _sunlight before, how about making adding a new field as well _suns / _suns2 which would add additional lights in a distributed pattern to create the GI effect?
I haven't experimented with it properly yet, but it'd be pretty cool to have it at base level in the tools.
#346 posted by Tyrann [130.220.71.26] on 2013/05/21 06:59:50
_sunlight is of course already there, but I will be adding _sunlight2/3 to emulate the bjp tools behaviour and I expect I'll add another mode where the light sources are more evenly spread.
Cool
#347 posted by ijed [186.79.239.140] on 2013/05/21 15:33:11
Do you still need the test maps? Not in the office today....
Tyrann
#348 posted by mfx [78.48.121.111] on 2013/05/27 00:38:48
what does light.exe warning: no model has face xxxxx try to tell me?
seeing no drawbacks, just curious.
maybe Alpha func_walls?
#349 posted by Tyrann [203.122.220.108] on 2013/05/27 08:48:20
Light checks the face number against the surface start/end numbers in the bsp submodels to determine which model it belongs to. I think metlslime's newskip tool changes the start/end numbers of the models when removing skip surfaces but doesn't actually remove the faces from the bsp.
In that case it's harmless, but if you're not using newskip, I'd be curious to know how you got this error.
Tyrann
#350 posted by mfx [92.225.217.243] on 2013/05/27 17:09:01
using rebbs jury rigged tools, which support skip removal.
#351 posted by Tyrann [203.122.220.108] on 2013/05/27 23:18:32
Ok, I suppose I don't need to warn about that. It's just unused data that was left in the bsp file after skip removal.
Where...
#352 posted by mfx [78.49.154.74] on 2013/06/18 21:44:35
can i d/l the latest Version of your utils?
the ones On your site dont seems to reckon -addmin and -soft1 switches.
just got a new machine, trying to Set up from zero, but cant get my old cmdline to run.
Bug?
#353 posted by ijed [200.73.66.2] on 2013/06/18 22:58:20
It seems that targeting a light at an info_notnull crashes the light util.
Can't be sure of this just yet though, need to experiment some more.
Scratch That
#354 posted by ijed [200.73.66.2] on 2013/06/19 00:41:23
Whatever I've done it wasn't the spotlights - deleting has no effect on the crash.
Fixed It,
#355 posted by mfx [92.227.127.99] on 2013/06/19 23:35:13
totally different cause....
Ok...
#356 posted by ijed [200.73.66.2] on 2013/06/20 01:57:10
It seems I've got the same crash as mentioned by Qmaster - tjunc, related to liquid volumes.
#357 posted by Tyrann [130.220.150.44] on 2013/06/21 00:33:28
@ijed: thanks for the test case, hoping to get back to some coding this weekend.
Great
#358 posted by ijed [200.73.66.2] on 2013/06/21 01:43:54
The test is pretty messy though. I've been a worldcraft user for many years and there's a lot of things that it blinkers the user to that other editors don't.
So it's full of misaligned brushes and floating points. Other habits, like using the CZG Curve system blew up in my face and those sections I'll have to replace.
I usually have a new version per 24 hours, so can keep on throwing stuff at you once you're back into the swing of things.

Post A Reply:

Name: |
Title: |
Body: |

Website copyright © 2002-2013 John Fitzgibbons. All posts are copyright their respective authors.