#8782 posted by Ron on 2009/07/11 11:32:47
OK, thanks.
I thought it only had to do with speed, so gameplay doesn't become choppy.
#8783 posted by JneeraZ on 2009/07/11 11:57:34
Speed is a large part of the reason but there are other concerns, yeah.
Also
#8784 posted by ijed on 2009/07/11 13:59:04
There's lots of ways to build a map where full vis doesn't have to take weeks. Level of brush detail, turning details into func_walls, making LOS blocking 'doughnut corridors' putting clip brushes inside small holes and so on.
Its finnicky stuff to do, but it makes the map very easy to compile - which is important for betatesting, since not everyone has a powerful machine as mentioned. Some might be emulating in Wine or have other issues.
My Quake machine will have trouble on non-fullvised maps, for example - a decent incentive to keep my maps well built.
#8785 posted by JneeraZ on 2009/07/11 14:01:44
"putting clip brushes inside small holes and so on. "
I don't see how this would improve VIS times. Clip is a collision thing while VIS looks at the rendering side of things, right? If you meant plugging up holes with solid brushes then, yes, that would help...
Too Many Static Entities Is A Bad Thing
#8786 posted by RickyT33 on 2009/07/11 14:09:35
the consequence is that some static entities wont appear in game (like torches and stuff)
AguirRe's engine should tell you how many static entities you have and what the limit is (256 IIRC)
Take some out and replace them with other light sources (i.e. light textures)
Ok
#8787 posted by ijed on 2009/07/11 14:11:24
Not vis help, but general good building of the map.
For example putting a crate in the centre of the room on the floor or putting a crate in the centre of the room floating 2 units above the floor.
The second one is better (and invisible to the player) because it causes less subdivisions, which also helps compile time.
No. Wrong. Don't Do This.
#8788 posted by czg on 2009/07/11 14:39:28
Nevermind. I'm Wrong. But It's Still Dumb. And Makes Extra Portals.
#8789 posted by czg on 2009/07/11 14:50:47
Hmm
#8790 posted by nonentity on 2009/07/11 15:46:45
As CZG so eloquently explained, while this will indeed reduce subdivisions of the floor, the saving in VIS time/polycounts will be negligble when compared to the creation of many tiny, tiny vis portals under the crate (which'll slow down you VIS a fair chunk, especially if done with every crate in a level (there should be as many as possible))
Hm
#8791 posted by ijed on 2009/07/11 16:04:10
Fair point - I'll go back to my cave now.
#8792 posted by negke on 2009/07/11 18:32:54
It's not dumb. It can lower the polycount considerably (depending on the area) and I doubt a few additional tiny portals will slow down VIS "a fair chunk." There's a more definite risk of ugly shadows beneath/around the crates, though.
However, speaking of poor VIS design: I'm now (again) stuck at a slow portal with no progress for a full week.
Nasty
#8793 posted by RickyT33 on 2009/07/11 19:22:02
#8794 posted by necros on 2009/07/11 21:30:55
found something interesting out about the hipnotic rotating stuff.
had never noticed this before, but you can attach ANY entity to a func_rotating_*
as long as the entity's targetname matches the target field of the func_rotating_*, that entity's origin will be continuously updated to match the position and angles of the rotater. i haven't tried, but i suspect it may not work with bmodels because of the way quake handles those, but point entities (even monsters o.0) work.
i was able to build a func_rotating_train which had torches attached to it as it moved about.
the effect is kind of ruined if the rotater actually does rotate though, because the angles of the child entities aren't updated, only their positions.
#8795 posted by AEnoch on 2009/07/11 22:48:50
clip brushes would help with BSP times as it's already telling BSP what areas to not put hulls. Some of the best ways to avoid high vis times is to avoid small brushes, huge open areas, and overly complex geometry (which is boring to me.)
I've never really understood the entire fretting about vis time other than your giving up use of your machine while vis takes place. Why should it matter if it takes 1 hour or 1 day as long as the map has good game play, is built properly, and looks great?
Most people playing these maps aren't wondering how long it took to Vis. They're having fun hopefully.
Dear Programmers:
#8796 posted by grahf on 2009/07/11 23:05:02
Detail brushes have existed in Quake (1) for a long time.
http://quest-ed.sourceforge.net/files/mapc/qutils_2_src.zip
http://quake.chaoticbox.com/downloads/equakeutils.sit
It's a pity they've never been incorporated into more modern compilers, because they really do work to cut down vis times. I used pOx's eUtils quite a bit back in the dark days of mac quake editing. They even have nifty features the Quest tools don't, like non-solid detail brushes. So you can have your func_walls and func_illusionaries, but they still cast shadows etc.
AEnoch
#8797 posted by Lardarse on 2009/07/12 01:20:56
The problem is that, these days, people are making maps that don't so much take days to fullvis as weeks.
It wouldn't be so bad if this trend wasn't utterly unnecessary...
No Q1 Map
#8798 posted by ijed on 2009/07/12 02:25:16
I've ever made has taken more than ~5 hours to compile.
Someone's about to post a warp map compile of 6 hours to prove me a liar.
Remember that this is a mapping forum, on the mapping help thread - this is the place where we complain about vis times.
Yeah, But ...
#8799 posted by Ron on 2009/07/12 11:17:26
In reaction to post #8797 posted by Lardarse:
Yeah, but if someone was to come up with a decent map, about ID sized, who would take notice ?
If you look at the work of people like Ijed, Tronyn, CZG, Necros, Kona and Kell(to name a few of the best ever), it's almost all huge. And I like it.
ID's Quake was great, but what these people have made is so much better. Better even than all the crap games you can buy in the stores these days. Works of art that inspire people like me to try and come close to, even without having all the knowledge that they've got.
#8800 posted by JneeraZ on 2009/07/12 11:51:24
The size of the map shouldn't matter though. Proper construction and respecting the engine should result in reasonable VIS times. If you build a gigantic football field with bleachers, well, yeah, that will take forever to VIS but in my mind that isn't proper construction.
You can build a large map and still have VIS be reasonable.
Having said that, my current map is going to be a bastard once it's sealed. I've committed a lot of VIS sins and I know the VIS gods will punish me for it.
#8801 posted by JneeraZ on 2009/07/12 11:52:11
"Yeah, but if someone was to come up with a decent map, about ID sized, who would take notice ? "
A map the size of an id1 map that was nicely detailed and well put together would be well received I think. You couldn't duplicate the originals and get away with it anymore but that size of map isn't necessarily a problem, IMO.
Fuck Limitations...
#8802 posted by JPL on 2009/07/12 12:09:15
... do whatever you think is cool... And you end up in a 2 month fullvis map :P
#8803 posted by JneeraZ on 2009/07/12 12:15:24
I dunno. I guess I'm of the mind that you have to keep evaluating your 'return on investment'. A map that takes 2 months to VIS isn't necessarily 60 times better than a map that takes a day. It may just be built wrong.
Lack Of Skill / Knowledge
#8804 posted by Ron on 2009/07/12 12:36:36
I agree that lack of skill or knowledge is the bottleneck for people who start mapping. Even people who have been doing it for years could be making things more difficult for themselves without them ever knowing. That's why it is a shame that so many websites dedicated to map making are disappearing.
#8805 posted by spy on 2009/07/12 13:12:27
ID's Quake was great, but what these people have made is so much better
bear in mind that id's levels was made ~95/96, do you remember, any custom levels of such quality those years?
I'm With JPL
#8806 posted by Mike Woodham on 2009/07/12 13:41:07
If I build a map and people enjoy it, that's my return on investment (your pleasure is my pleasure, in a non-kinky way). I map for fun, not for money. My computer is not a 'resource', it's a hobby.
Sixty hour vis times is fine by me, I'll be doing plenty of other things in the foreground. So, time is not the issue: impatience might be.
|