 News | Forum | People | FAQ | Links | Search | Register |
Log in |
|
|
I still don't quite understand what they are, and the tips aguirre gave me were really specific to my map, so probably wouldn't help you.
Best bet is probably to try pestering aguirre about it, he's wonderful for map fixing. =) Well, I don't know. I just finished the final build of the map concerned by this issue (it's ready for release, I will post it friday evening).. I changed the wind tunnel into a "walking" tunnel... sorry for this...
Anyway, thanks for the tips: I will try to make a test and see if it helps. Well, it's pretty weird effectively. In "Castle of the Dark Ages" map, I had 35k marksurface / 31k clipnodes (if I remember well) and the map didn't crash at all... It sounds to depend also of your PC performances as well... though...
The last possibility you have (if you don't want to change too much your map), is at least to add a note (in txt file) to player stating that only aguirRe's GLQuake will support your map. Good luck. generic: ok, i suck. i had the numbers right already, but it didn't work because of the think/nextthink fields preach used.
unfortunately, it didn't work out (or at least i couldn't get it to work properly): either there is a model that can't be removed, or a model that still rotates. check the useless test maps here: http://negative.net.tc/files/wtest.rar so i have to give up on this :/ mike: stupid idea maybe, but what about creating new textures - walls that already have trims, details etc. - to reduce brushes and therefore possibly marksurfaces (dunno if they are even related) than: The various Q1 limits are today a pretty complex issue. In general, you have various tools and engines, file and protocol formats and even bugs that all cooperate to make things difficult. Also, the network protocol isn't just for "networking"; it's always in use since the engine is built with a client-server design. Even demos are completely protocol bound, as they are in fact just recorded server network messages.
I'll just try to comment on your qbsp printout. The only limits you're close to or exceeding are the clipnodes/marksurfs, both must be <32k for normal engines. Clipnodes I've commented in my ToolTips, but marksurfs are more difficult. Search this thread for numerous comments. And yes, the rightmost qbsp printout numbers are lump sizes in bytes (not very useful for most people). neg!ke: The standard engine command for model printout is "mcache". I'm not sure it'll give you what you're after, though. You do suck on so many levels :p but I will download your crappy test map anyways (because I tend to download anything you do :) ) and continue to turn in my speedmaps late ;)
Thanks for all the effort anyways but I have already come up with a separate solution. I never really needed the items to "work" -- I just needed them to sit still and look pretty :p the elusive marksurfs limit, it doesn't depend on computer speed or anything similar. When the limit is exceeded in an engine that hasn't fixed the 32k bug, engine internal memory is trashed.
As with all memory trashing scenarios, it may or may not affect functionality depending on how the memory is used at that time or later. Since IIRC this particular memory is on the Quake heap, it may help to change heapsize. As I understand it, marksurfaces are just polygons. So basically every visible brush face in your map is one or more marksurfaces. It becomes more that one marksurface if:
- It is bigger than 240 pixels in x or y texture directions - It is intersected by another brush/surface - A t-junction lies on one of it's edges Two ways you can reduce the number of marksurfaces are to do with textures. You can combine them as suggested by neg!ke (i.e. reducing the number of brush faces in the first place). Or secondly, you can scale up textures in places if appropriate, to reduce the amount of surface subdivision taking place. JPL: I use Fitzquake080 as standard, which is great for everything except synconisation of flames and use of music files direct from the HD. I am not sure that aguirRe's engine is used by enough people.
neg!ke: I try not to use trims combined in textures because we get the "painted on trims" rant from Shambler everytime! And I've probably said that too loud, Shhhh, he'll wake up. Tyrann: I just did a test on the smaller of the two maps - First, an oft used texture (ground1, which is normally 128 x 128) at 64 x 64:- 11016 planes 220320 31312 vertexes 375744 12616 nodes 302784 2670 texinfo 106800 24475 faces 489500 26354 clipnodes 210832 6924 leafs 193872 30786 marksurfaces 61572 113476 surfedges 453904 57059 edges 228236 133 textures 1915296 lightdata 0 visdata 0 entdata 72453 and then the same texture increased to 256 x 256:- 11016 planes 220320 31312 vertexes 375744 12616 nodes 302784 2670 texinfo 106800 24475 faces 489500 26354 clipnodes 210832 6924 leafs 193872 30786 marksurfaces 61572 113476 surfedges 453904 57059 edges 228236 133 textures 1996896 lightdata 0 visdata 0 entdata 72453 Only the texture lump changed: marksurfaces stay the same. Still, just looking through the map again has roused my interest. I might chop out one of the side-rooms and at least try to release something playable. No, that won't make a difference. What I was trying to say is that you could set the texture scale in the editor higher than 1 (i.e. stretch the textures).
I stretched a rock texture to 2 x 2. I am not sure which texture I got rid of (by accident) but it still doesn't help marksurfaces although some of the figures have changed:-
11016 planes 220320 31285 vertexes 375420 12751 nodes 306024 2665 texinfo 106600 24640 faces 492800 26185 clipnodes 209480 7001 leafs 196028 30882 marksurfaces 61764 113902 surfedges 455608 57276 edges 229104 132 textures 1926132 lightdata 0 visdata 0 entdata 72453 Mind you, I think the rocks look better now! I don't really see how that could cause a marksurface increase like that, but it may not result in a reduction if the polygons aren't that large to start with. I agree that rocks/grass do tend to look better with a higher scale when there's a lot of it - I'm currently using a 1.5 scale on mine.
If anyone is using this plugin to manage Q1 PAK files, you might be interested in some improvements I've been working on lately.
I'm currently not considering a public release, so if you're interested, just email me. http://www.celephais.net/board/view_thread.php?id=4&start=1736&end=1737
P.S. Yes, this means I finally coded a way to specify a range of posts. Thread paging is a little bit closer. About texture scale in relation to marksurfaces is very useful, upping the scale of sky textures, and trigger texture (I have lots of very large trigger_hurt brushes in my map) can lower the marksurface count considerably.
I still fail to understand why these limits still exist, but that's probably just because I'm stupid. Oh, and metl, I luv you. Had a bash at this, think I've got a good fix, at the least there are some interesting ideas that result from it. It's not possible to make the actual nailgun model stop rotating without modifying the model file, the rotate flag can't even be overridden in QC. So what this map does is creates a bsp model that approximates the nailgun, and has that in the map. You'll want ogro's texture wad if you want to see it in all it's glory.
http://www.btinternet.com/~chapterhonour/weptest.map Ok, so I'll explain what all the entities do. The func_wall in the second room is just there to make the compiler compile the brush entity we need, so that it has modelindex 2. After the map is compiled you could safely remove this entity with adquedit or something. One thing to notice is that it's been very carefully placed near the origin. This is so its easy to place in the map with the next entity. The next entity is the one that makes it visible but non solid, the point entity info_notnull. This uses the SUB_regen hack to load a model by it's modelindex. The modelindex is set to 2, so it loads the nailgun model we just made. The model and mdl fields are necessary dummy fields, as long as they have some model in then it works. Why didn't we just use a func_illusionary? Because this way, the entity isn't static, so we can killtarget it. The standard trigger_once kills it when we touch it. At the same time the player touches the trigger_once, they will also touch the brush info_notnull. This uses the good old trigger hack, so we can make a brush trigger with an arbitary touch function(look at the think and nextthink to see how it works). This time we set the touch function to BackpackTouch, and then the rest of the fields are set to match a backpack that only contains a nailgun(items 4, netname nailgun, ammo_nails 30). The BackpackTouch function can be used as a trigger in more general situations. You could give it a netname of "weapons" and then set the items field to some sum of weaponflags to give all those items at once. Be warned though, if the player already has any of those weapons the message will skip straight to the ammo summary. A good way perhaps of giving the player weapons on startup would be to use this trigger with no ammo, and netname "\n\n\n\n"(enough backslashes to push the "you got" message offscreen). You can also set any of the other itemflags, but most of them won't do anything. The powerups flags will tint the screen, but won't actually give the player anything. Similarly the armour flags will only make a cosmetic change. The keys, however, do work as you expect, so you can give those out by trigger. Potentially you could try removing items this way as well, but I haven't got it to work...Anyway, have fun with that. there are so many holes in quakec, you wouldn't even be able to contain molasses in it! :o
good job on figuring that out, dude! P.S. Yes, this means I finally coded a way to specify a range of posts. Thread paging is a little bit closer.
thank you! :D this will make searching through the larger threads a lot easier, as mozilla kept crashing when loading more than 1k posts at a time. (too much quake goodness in the same page? :P ) cheers, dude ^_^ I have been given a monster in
I have access to 3DMAX and/or Maya7 for several hours per week. I don't use them and know nothing much about them. Which should I try to learn, and I don't have time to learn both and make an informed decision, to a) reduce the tris, b) animate the monster. Also, what should I use when it comes to skin the monster. Mmmm..., am I expecting too much? Qmle should get you on your way, but I think you knew that already.
http://www-static.cc.gatech.edu/classes/AY2000/cs4455_spring/planetquake/modediting.html it's really hard to make a decision between max and maya as they are both excellent modelling programs.
however, if you're just doing this for quake, i'd say max might be your best bet. i found it was slightly easier to learn than maya. the only real reason to pick maya over max would be if you were going into the industry, maya is more widely used. but max has excellent tools for modifying meshes to reduce polycount, and it has fully developed bones/animation system. as an example, all the animation for the quoth monsters was done in max. but i won't lie to you... it will take you a long time to learn all the tools. there are just so many. but once you do, pretty much anything is possible. Alias was recently aquired by Discreet (the company that makes Max), so perhaps the two will become more and more alike. I doubt either will be phased out, however, as they both provide Discreet with a nice revenue stream at the moment.
I find Max a lot easier to learn, less buggy (we are talking recent versions here) and with a generally better interface. Maya has a lot of nice features that Max doesn't have (last time I checked), but some of the basic modelling features of Max just shit on those of Maya - the interface for using them is generally loads better too. I've heard that Maya is better for texturing and animation, and whilst the animation side seems really good (not that I have done anything complex, but it is very easy to set up a skelton, weight a skin and get animating). The texturing features of both programs are not too different, but I find Max a little easier, perhaps because I was already used to the rest of the program when I tried actually skinning something with it (I used to use in-house tools at my previous job for level texturing, which were better than both Max and Maya :) I find Maya requires the user to do a lot of extra selection and deselection that Max does not require, making Max slightly easier to work with and more time-efficient. Madfox: thanks for that link, it was very informative although most of the links on that page were down.
necros/than: OK, I guess Max it is. I've already had a first look at the program with a one hour session last night. Gulp! I have a very tatty copy of 3DSMAX Bible so on my next session I am going to try to make the Three Fingered Gaaboot and we'll see what transpires. Thanks chaps.
|
|
| You must be logged in to post in this thread. |
|
| Website copyright © 2002-2024 John Fitzgibbons. All posts are copyright their respective authors. |