What RickyT23 Said
#12959 posted by Drew on 2013/05/24 23:49:02
What Drew Said ;)
#12960 posted by mfx on 2013/05/25 01:40:05
What Others Said :P
#12961 posted by JPL on 2013/05/26 08:37:52
Warning:
#12962 posted by Rick on 2013/05/26 10:23:09
Warning: 256 Models Exceeds the Standard Limit of 256.
Okay, so what is it really? 255? Or do I actually have more that 256 and it's just not telling me?
256
#12963 posted by negke on 2013/05/26 10:58:39
It will still load in unmodified ports despite the warning. You just can't add any more if you want to keep it vanilla.
If this or any of the other limits become a serious problem in your map, feel free to give me a shout. It seems I'm getting pretty good at optimizing these things... :P
If You Have A Lot Of
#12964 posted by RickyT33 on 2013/05/26 12:10:18
func_illusionary details, try grouping some of the ones that are close together into one model.
Sorry
#12965 posted by Rick on 2013/05/26 12:30:58
I well understand the limits and have gotten pretty good at optimizing stuff. What I was pointing out is this:
256 exceeds 256
Which it actually does not.
I'm guessing it has to do with counting that starts at zero instead of one. I probably have 257 models.
I've been adding one unnecessary func_wall off and on over the last several builds just to see how close I was to the limit.
I'll take one out now and the warning should go away.
Nevertheless, 256 is not more than 256
The good news is, I still have 5 or 6 models left to play with :)
#12966 posted by Spirit on 2013/05/26 12:36:06
It's probably a counting issue and a bug of that message. The index would 0-255, the range of that is 256 items. So the model with index 256 would be one over the 0-255 range as it is actually the 257th model.
#12967 posted by necros on 2013/05/26 19:07:40
negke: are you sure > 256 models loads in engines that don't support it? i remember having to remove bmodels from some maps like nesp09 because there were over 256 and it was crashing the engine.
#12968 posted by negke on 2013/05/26 19:11:46
What I meant is that a map with exactly 256 unique models will still load despite the warning in Fitz and BJP. Anything above that number will cause a crash.
However
#12969 posted by Preach on 2013/05/26 19:57:23
It might load, but I suspect that you'd have problems with model 256. The limit is because vanilla quake sends the model value as a single byte over the network. If you try and send 256, the server's going to send 0 instead - and 0 is interpreted by the client as "no model". As long as you're happy with the last model only being visible in engines with higher model limits, you can have 256.
#12970 posted by metlslime on 2013/05/26 21:51:30
the message is slightly buggy i think. The true limit is that a model with index >255 will break the network code on protocol 15 (you'll have some invisible entities.) So 256 models is okay, 257 is bad.
The bug in fitzquake is I used >=256 instead of >256 as my check for displaying that message.
HOM
#12971 posted by Cocerello on 2013/05/28 11:01:28
As we were talking about it in the thread of mfxsp6 and in others, i became more curious about it, and want to know more before i get this one in my maps. So i ask:
What is HOM exactly? What causes it? How do you fix it?
Hom
#12972 posted by Vondur on 2013/05/28 11:39:28
it's the polygons that are not being rendered.
this happens if you have erroneous brushwork: too little trianlges, too many intersecting edges on one face, textures of various nature touching each other (water+sky or something). or just huge room with too complex geometry, bsp-vis compilers just can't cope and make erroneous polygons.
so just build clean and simple and with r_speeds in mind and you'll never get this hom thingy.
Also
#12973 posted by ijed on 2013/05/28 17:21:28
It stands for Hall Of Mirrors.
#12974 posted by Rick on 2013/05/28 18:10:04
I don't know about other engines, but in Fitzquake if you set gl_clear 0 and noclip outside the map, there will be HOM everywhere that's empty space and you'll see why it's called "hall of mirrors".
Yeah
#12975 posted by RickyT33 on 2013/05/28 20:24:32
I had an idea about doing it on purpose using skipped textures. For that crazy 'down the rabbithole effect'.
Anyone:
Has that been done yet? I think it could work really well, maybe having chunks of other realms in weird positions as the player moves through some sort of rift. I nearly had a go on my last release.
Hmm
#12976 posted by Drew on 2013/05/28 21:32:13
for me HOM as an effect is ruined by it's associations with errors, problems, bad mapping, whatever
#12977 posted by necros on 2013/05/28 21:34:06
might be interesting as a breaking the fourth wall type of map
Marksurfaces Are Evil Part 2
#12978 posted by Rick on 2013/05/29 00:52:38
Okay, I've been having to go very slow with making changes. Basically I'll make a few changes, only in one particular area, then copy the map over to my fast computer and BSP it. If the difference in marksurfaces is reasonable, I keep going, otherwise I start hitting the undo button.
Today I cloned a light fixture, not very big and kind of detailed, made from about 12 or 13 relatively small brushes. Connects to the wall at a 16x16 section of brush.
Copied the map and ran TxQBSP. When I saw the marksurfaces number I almost fell out of my chair. The increase was from 32,258 to over 33,000 !?!
Started thinking, well that light fixture didn't really look too good in the map, and there's two others exactly the same, I'll delete them all and maybe get a reduction of a thousand or more marksurfaces. Wrong.
New marksurfaces was only about 100 less, which is probably pretty close to how many surfaces there actually were on the two fixtures.
I'll take what I can get, back to mapping.
More Marksurfaces Stuff
#12979 posted by Rick on 2013/05/29 21:02:07
I worked at trying to reduce marksurfaces all day yesterday. It seemed like every time I simplified brushwork, the marksurfaces went up. I remembered negke's comment about rebb's modified txqbsp, so I downloaded that and gave it a shot. Magic.
Using the -forcegoodtree switch I got an immediate reduction from 32,266 to 31,763 with no other changes. That's some breathing room. Which is good because I had more stuff to add that was absolutely necessary.
I added another small room with an elevator and an arched doorway. I recompiled the map and... more magic. Marksurfaces went down again, by over 250!
I'm now at 31,507 and I think my marksurfaces problems may be over because there's not much more stuff that needs to be added.
I did a full compile and played it through to the end, looking for any bsp errors the whole time and didn't see any problems at all.
YES
#12980 posted by Drew on 2013/05/30 03:24:55
So pumped to play this!
Rebb Did Some Good Job There.
#12981 posted by anonymous user on 2013/05/30 13:55:38
BSP Tree Hug
#12982 posted by rebb on 2013/05/30 18:43:37
It's still very much an experimental switch, but it does help with marksurface counts - the only side-effect seems to be a somewhat less efficient PVS in some cases.
A few well placed hint brushes should help if needed though.
It would be nice if someone with a much better insight than me into the dos and don'ts of BSP creation could take a peek at the code ( it's a super tiny change in qbsp.c ) and confirm/deny if this is actually a horrible idea ;)
..sorry Maybe An Outdated Question
#12983 posted by deh on 2013/05/31 00:25:11
Do guys know if and what version of the programs QME and WORLDCRAFT may be used in commercial works ?
tHaNk in advance
|