View Full Version : r_speeds!

02-16-1999, 11:23 AM
okidoki! i have one but VERY important question and it that: what is the optimal r_speed value and what is the limit when it becomes unplayable (on slower machines) i cant do this by trial and error style cuz i have so kick ass comp http://www.ritualistic.com/ubb/images/icons/smile.gif i usually never get less than 50 fps even in 1024x768 so i want to ask opinions...
(enjoy my great english again!)

Tatuone <TF>
visit our site at

02-16-1999, 12:43 PM
Ok, this is a very important issue you have raised here, dude. I will elaborate on it for the benefit of everybody on this board.

r_speeds is a very essential tool to use when you're make maps. This will basically tell you how many world and entity polygons the game engine can see depending on where you stand and in what direction you're looking in your map.

You enable it with the console command:

r_speeds 1

And a series of numbers will be displayed on your screen. The type of figures depend on what mode you're in: software rendering or 3D accelerated (OpenGL or 3Dfx).

Software mode example:

26 ms 160/ 98/ 54 poly 0 surf 31.19 fps

If you want more details on how to interpret those figures, there is a section in the Quake2 techniques at Rust that explains this so I won't retype it here. The only difference is that in Sin, the fps figure was added at the end of the line but the rest is 100% identical. Here's the link to that page (scroll down to the r_speeds paragraph in the page):

www.gamedesign.net/quake2/quake2techniques.shtml (http://www.gamedesign.net/quake2/quake2techniques.shtml)

3D accelerated mode example:

131 wpoly 384 epoly 0 tex 1 lmap 59.9 fps

The first figure (131 wpoly) means 131 world polygons. This is the number that the engine sees, this is the IMPORTANT one. The one you always have to keep your eye on because it's the figure that will determine how fast or how slow your map will be.

The second one (384 epoly) means 384 entity polygons. This one is less important but there's a limit you shouldn't exceed either (sorry but I don't remember, it's in the order of 1000 or something. Feel free to correct me anybody if you know better).

The last figure gives the estimated fps (frames per second) but this figure can vary depending on what kind of machine, how much memory and what kind of 3D card you have so you DON'T RELY on that figure. You rely on the wpoly count. This way, you make sure that your map will be playable by people who have slower machines (because not everybody has a P2-450/128Mb + 3D card).

So the lower the wpoly count is, the higher the framerate will be.

Levelord once said:

"wpoly count is GOD or the devil himself http://www.ritualistic.com/ubb/images/icons/smile.gif"

He is your ultimate Master. Do not displease him for his wrath is unforgiving and ruthless. http://www.ritualistic.com/ubb/images/icons/wink.gif Many maps of mine were scrapped because of my ignorance of his whims.

For single player maps, this figure should, in principle, never exceed 600 (but some say up to 700 is acceptable). For multiplayer maps, it should NEVER exceed 600 and some say that in areas with lots of traffic (IOW, lots of players and carnage), it should not exceed 400 - 500.

The more brushes you put in a room (columns, beams, trims, decorations, etc.), the higher this figure will be so you have to be careful not to put too much stuff in there. The basic idea is to strike a balance between the amount of details (number of brushes) and framerate. Too little detail and the map looks dull and boring. Too much detail and your map won't be fun to play because it's too slow and will lag everybody in the game.

There are many more issues that will affect your wpoly count in a map. Fortunately, Sin is a very evolved technology 3D game and there are techniques that can help you in keeping your poly count down. For this, David Hyde, Richard Neff and Mad Dog wrote the best tutorial ever on the subject for Rust. It's a Quake2 tutorial but everything in there applies 100% to Sin maps so it's a MUST READ:

www.gamedesign.net/quake2/tutorials/poly_reduction/tricks.htm (http://www.gamedesign.net/quake2/tutorials/poly_reduction/tricks.htm)

02-16-1999, 02:05 PM
Yeah, I know. I've been there. I know what you feel and it IS a bit of a heartbreak.

But don't worry. This is 100% normal. ALL map designers have to go through this phase. When you realize all the cool details you can do by shaping and texturing brushes, your initial reaction is to go crazy and totally overboard with brushes.

I did EXACTLY the same thing when I started.

But this step is really VERY useful because:

1. Once you know, you'll never forget.

2. It's excellent practice in shaping and texturing brushes and practice is what counts the most in learning how to make maps.

So considering that you started from scratch only a few weeks ago, your progress is actually excellent http://www.ritualistic.com/ubb/images/icons/smile.gif

At least, you're trying and making stuff and learning! That's 90% of the whole thing right there.

So just keep doing what you're doing and eventually, you'll get to where you want to be, it's only a matter of time.

The Node
www.ritualistic.com/node (http://www.ritualistic.com/node)

The official Sin entities and scripting reference site

02-16-1999, 02:32 PM
i sure am glad that this phase is going over!
And u r totally right i founded out that how few architectural changes (pillars, beams stuff like that)can make level look really good and it could be done by just little vertex editing and texture align and guess what http://www.ritualistic.com/ubb/images/icons/smile.gif? i got absolutely mad i did vertex editing to make incredibly good looking pillars and decoration straight from heaven
but then like big fist straight from sky hitted me back in this world and this fist was wpoly count, now i am readed that great rust article (everyone should read it!) and have gained lots of tips, and i think that if i try hard (and i will http://www.ritualistic.com/ubb/images/icons/smile.gif )i can reduce that wpoly count to reasonable 500-700
without much heartbreaking detail deleting.
i know this cause i did these things
1: i used LOADS of subtraction (very bad!!)
2: i didnt know that qvis has bad habbit to chop walls in different parts if they hit to each other ( this is easy one )
3: i have used no areportals (duh http://www.ritualistic.com/ubb/images/icons/smile.gif )
4: i have none func_walls
and list goes on...
but now i am going to edit my map and start this hard fight against wpoly counts!
btw: about that progress, i really do feel my self that i have progressed alot in past few weeks, i even have fully working script
(pretty basic but still!) and i am learning everyday! and eutectic u r absolutely right
i want to know more everyday and have that good feeling that i have achived sometihng
no matter if its rotating door or fully working script! Now i am starting fit pieces together and realising the wonders of level editing, and i really like it http://www.ritualistic.com/ubb/images/icons/smile.gif

Tatuone <TF>
visit our site at

02-16-1999, 05:44 PM
And I'm glad you're taking it so well http://www.ritualistic.com/ubb/images/icons/smile.gif

Let's examine a few points in detail here and see what should be mentionned:

<BLOCKQUOTE><font size="1" face="Verdana, Arial">quote:</font><HR>i think that if i try hard (and i will)i can reduce that wpoly count to reasonable 500-700 without much heartbreaking detail deleting.<HR></BLOCKQUOTE>

You certainly can. If you take a look at the maps designed by the Ritual guys, you will see that these guys managed to make things look good without sacrificing too much detail. The key here is balance.

Among the things that affect poly count are not just the amount of brushes but also:

1. The size of your rooms

2. The number of different angles used in your shapes

3. How your rooms interconnect with your corridors

On the first point:

The general idea is if you make a large sized room, you can afford less detail. A smaller room can have more detail. It's basically a trade-off.

On the second point:

Man! Those complex and numerous angle shapes like arches, multi-faced columns, pipes with intricate flanges, spiral staircases right in the middle of a large room, spherical or oval shapes... Don't those ever look great eh?...

Unfortunately, there are murderous for poly count and they tend to create a lot of extra portals thus increasing VIS time. So even though angled brushes do add a lot of "gusto" to the aesthetics of a map, you really have to go easy on those and try as much as possible to stay within a limited number of different angle values.

Here again, it's a question of balance. Maps with only square brushes (all 90 degrees angles) would be ideal but can be somewhat "too plain" so angles are necessary. The trick here is to exercise moderation.

On the third point:

Sometimes you want a corridor to connect 2 rooms together without doors (so you can't use areaportals in this case). It's important to use bends (like the donut hallway principle) and obstacles (like a piece of wall, a ledge or a large crate in front of that entrance to block vis.

In many cases, the wpoly count will be high in a particular room not because the detail in that room is too high but because VIS can see into the next room and thus all the detail that's in that next room as well!!

Oh yes my friend! Always remember this:

What your eyes see in the map and what VIS sees are 2 DIFFERENT THINGS!

(by VIS, I mean the game's 3D rendering engine BTW)

This is VERY important to grasp.

Let's say for example you make 2 plain square rooms. Then, you make openings in each of them and make a short L-shaped corridor between them. When you stand in the middle of one of the rooms, your eyes can't see the inside of the other room right?...

But chances are that VIS can "see" in there tho.

But "How can I tell whether VIS sees in there or not?" you ask...


By using the console command:

r_draworder 1

This is r_speeds' big brother and your best friend http://www.ritualistic.com/ubb/images/icons/smile.gif

It will show you exactly what VIS sees by drawing the farthest brushes first and the nearest brushes last. This way, you can tell if your poly count is too high because your room has too much detail or because VIS sees both rooms at the same time and ADDS the poly count of one to the other. Capiche?

BUT... In order for this to work, you have to compile your map with a FULL VIS and NOT a fast VIS:

qvis3 yourmap (don't use -fast)

But despite the increased compilation time, you will learn to LOVE this tool. I know I do http://www.ritualistic.com/ubb/images/icons/smile.gif

Then if you discover VIS can see in the next room, it's often a matter of elongating a corridor, adding an extra bend or visual blocking obstacles (crates, a big square column or wall partition). Remember that solid entities (func_walls, doors, etc) do not block VIS.

Now let's move along to the next points:

<BLOCKQUOTE><font size="1" face="Verdana, Arial">quote:</font><HR>1: i used LOADS of subtraction (very bad!!)<HR></BLOCKQUOTE>

Yes very much indeed. Good editors like WC, Qeradiant, Qoole, Quark and SinEd all have the essential vertex and edge manipulation + plane clipping features. This has become a de facto standard and any editor which does not have these features is not even worth considering period.

When I first started using vertex manip. and plane clipping, I instantly fell in love with it. Not only does it make it a LOT easier to make the shapes exactly the way you want them but it makes a much cleaner job. From that day, I swore an oath that I would NEVER use brush subtraction again and I have had no trouble keeping that promise since http://www.ritualistic.com/ubb/images/icons/smile.gif

I'll post a few tip & tricks on this later on...

<BLOCKQUOTE><font size="1" face="Verdana, Arial">quote:</font><HR>3: i have used no areaportals<HR></BLOCKQUOTE>

Those are also your friends and they're easy to use. Always place one in your doors whether sliding or rotating or sriptdoors UNLESS your door has a window in it of course http://www.ritualistic.com/ubb/images/icons/smile.gif

<BLOCKQUOTE><font size="1" face="Verdana, Arial">quote:</font><HR>4: i have none func_walls<HR></BLOCKQUOTE>

Ok, this has never been mentionned before. zied (of 2015) has warned me against the negative side effects of this. Apparently, the brush faces that belong to an entity take 10 times longer for the engine to render so beware!

IMO, it's much preferable to use detail brushes instead unless that brush is intended to block VIS (detail brushes just like solid entities don't block VIS).

And that's all for today folks http://www.ritualistic.com/ubb/images/icons/smile.gif

The Node
www.ritualistic.com/node (http://www.ritualistic.com/node)

The official Sin entities and scripting reference site

Halo BaS
02-16-1999, 06:51 PM
Man ,you guys scared the hell outta me !
I was sure my masterpiece was going to be a wpoly nightmare( lots of detail, or so I think)
but I did the test and it conforms in all respects(to what was said above)
highest wpoly count at largest area is 459 with 59 fps , !
Thought I was gonna have to trash this thing!
Thanx for turning me on to this , great tool for the "what if I...'s"

02-17-1999, 01:26 AM
LOL! http://www.ritualistic.com/ubb/images/icons/smile.gif i have taked diferent aproach my man
http://www.ritualistic.com/ubb/images/icons/smile.gif i just checked r_speeds from my level and
the middle area (center of all action) the
wpoly jumped in 1100 http://www.ritualistic.com/ubb/images/icons/smile.gif and we r talking about multiplayer map here... well now i have 2 options first is take all mine kewl
details away (which i dont like cuz i have been doing details for days now) or i should do some SERIOUS architecture changes so that it would mask my pretty details and that u cant see it all same time... either way
i feel bad http://www.ritualistic.com/ubb/images/icons/frown.gif BUT well i guess lagless
multiplayer experience here what we r looking for.. so my map schedule is going back days (if i find it hard maybe week or two) hmph i guess i should asked this question more sooner http://www.ritualistic.com/ubb/images/icons/smile.gif well but now i am going to take indepth look for those rust articles and learn my lesson with hard way.
But thanx for clearing my problem Eutectic
now i will watch those speeds http://www.ritualistic.com/ubb/images/icons/wink.gif
and BTW: i checked some sin orginal mplayer maps and in skeen i topped 1100 wpolys too http://www.ritualistic.com/ubb/images/icons/wink.gif
hehe ok but i am da off now thanx for reading http://www.ritualistic.com/ubb/images/icons/smile.gif
(and as always enjoy my great english)

Tatuone &lt;TF&gt;
visit our site at

02-17-1999, 02:17 AM
this is really weird! i added areaportals
did one dougnuth hallway (to block my too big hallway) re-brushed walls that had bad subtrack signs, did few detail brushes
etc etc i was really exited when i started my map in SinEd and turned R_speeds on...
! what i had actually made wpoly count HIGHER!!!! now its 1400 in center area
(and i didnt do fast vis so it cant be wrong)
i have no clue how have i made that...
i think i have to start from scratch...
and what is wrong cause I cant turn r_draworder to 1 is this same kinda thing like gl_showtris and wont open with 3dfx card without mesa open gl drivers?
halo: grrr http://www.ritualistic.com/ubb/images/icons/smile.gif would u give your wpoly count to my map too? hehe, no seriosly good that u have started to check r_speeds too and maybe u will not face this problem what i have now.
but now i am going to open my sined and start
this project again!

Tatuone &lt;TF&gt;
visit our site at

[This message has been edited by Tatuone (edited 02-17-99).]

Halo BaS
02-17-1999, 02:36 AM
Believe me man ,
it was pure luck , although I did read an article on Rust which planted this idea in my design-
The thing I remember it stressing was; keep everything out of sight of everything else , bends, doors, and always low poly count!
and avoid those big open areas.
But I haven't sacrificed the detail I wanted to achieve.
Good luck , I know I have been there, this is the 4th map , and maybe I'll actually get this one flying http://www.ritualistic.com/ubb/images/icons/smile.gif

02-18-1999, 12:51 AM
Hmmm... about the draworder thing Tat, I checked in SiN and it works in 3dFx mode, in software mode and even in Default OpenGL mode with the Direct3D wrapper for my Matrox G200. Works fine in all modes.

I haven't tried Riva or ATI rage or Power VR modes of course because I have a Voodoo2 card. What kind of card do you have?...

And about your r_speeds problem, I understand your frustration. It's impossible for me to tell what it could be since I can't see it. We really have to get r_draworder to work on your machine. Try going to software mode and try it again and let me know. It should work.

Once you have that working, you'll be able to tell what's causing such a high poly count. Maybe you rooms are too big, I dunno.

02-18-1999, 03:04 AM
hmm i tryed that draworder again, yet again it seems that i cant turn it on! i tryed in software and default OpenGl with my i740
and then i tryed 3dfx mode (i have dual voodoo2) nothing.. when i start game (i am not yet in any map) and type r_draworder 1 to console it changes value but in game it automatcially turns draworder to 0 and it doesnt turn it on even if i try... and yes main hallway is quite big room i think its 1024x2048 (without checking cant be sure tough), any ideas left? http://www.ritualistic.com/ubb/images/icons/smile.gif

Tatuone &lt;TF&gt;
visit our site at

02-18-1999, 09:53 AM
Hmmm.... I must admit I'm totally baffled as to why r_draworder doesn't work because I can't see any reason why it shouldn't.

Anyway, about your main room, that's quite large. How high is the ceiling BTW?

I think while at the limit, it's feasible to have this size room, you can't afford to have very much detail in it IMO unless you find a way to place obstacles in it that can somehow block VIS...

The Node
www.ritualistic.com/node (http://www.ritualistic.com/node)

The official Sin entities and scripting reference site

02-18-1999, 10:40 AM
http://www.ritualistic.com/ubb/images/icons/smile.gif i solved my problem it was all because one wall was few units from ceiling and u could see another big room from that (it was on quite sneaky place http://www.ritualistic.com/ubb/images/icons/smile.gif ).. well now i blocked that hole and wpoly count dropped to 700-750 http://www.ritualistic.com/ubb/images/icons/smile.gif so thats clear but i still cant figure that r_draworder prob http://www.ritualistic.com/ubb/images/icons/frown.gif
BUT now i get these strange warnings when i am compiling Vis, i am too lazy to write it here http://www.ritualistic.com/ubb/images/icons/smile.gif so i toked photo off it (100 kbit or so)http://www.saunalahti.fi/~tluostar/dmtf6.htm
any ideas what that might be?

Tatuone &lt;TF&gt;
visit our site at

02-19-1999, 10:13 PM
r_draworder was q1. In q2 (so I'm guessing sin as well) has sv_draworder, but that only does it in software mode.

There is also another nifty command, gl_lockpvs. To use it, put this in your autoexec.cfg:

alias p_h p_off
bind f2 p_h
alias p_off "alias p_h p_on; set gl_lockpvs 1; gl_clear 1"
alias p_on "alias p_h p_off ; set gl_lockpvs 0; gl_clear 0"

Press f2, and walk around. the stuff still visible is the stuff the vis can see (only what was in your fov, of course, as there will be stuff visible behind you).

Also, why hasn't anyone mentioned hinting? Hinting is a great way to lower r_speeds. There's a hinting tutorial in the q2 tutorials on rust.

[This message has been edited by jednet (edited 02-19-99).]

02-20-1999, 12:57 AM
r_draworder works in Sin both in software and hardware mode. I use it all the time so I'm not GUESSING here. I know it works.

Didn't try the lockpvs thing tho (didn't need to with draworder).

And nobody mentionned "hinting" (you mean the use of hint brushes) because these are almost impossible to use right if your graphic card doesn't let you do a gl_showtris and even the TNT doesn't.

I tried that special driver patch (whatchamacallit again) that supposedly makes gl_showtris work with a Voodoo2 card in Quake2. Works fine!... until it crashes your game.

Then I downloaded one of the example maps I found in another Quake2 tutorial. One of those was a huge open area made from valleys and hills. The trick worked... the r_speeds was amazingly low for such a huge open area.

Only problem tho is that when you tried to jump in the game (not jump off a cliff, just a normal jumping up and down on the spot where you're standing), the player would take damage for absolutely no reason (??????) and eventually die for no reason.

So when I saw that, I said that's it. Those are too wierd, too unpredictable and I can't see their effect because I have no way to use gl_showtris to see where I should place them so they're not for me.


Only a very select few experienced designers who REALLY know what they're doing AND have the right hardware can use hint brushes in a favorable and reliable way.

For the rest of us mere mortals, my best guess is that we'll just have to use common sense and trial and error. The best way is to check as you build and prevent the excesses instead of trying to fix them at the end.

02-24-1999, 07:41 PM
All the great editing commands that were in Q1, that were taken out for Q2, Ritual put back in in SiN http://www.ritualistic.com/ubb/images/icons/smile.gif. Here's a list with some additional ones:

r_draworder 1/0
r_drawflat 1/0
r_speeds 1/0
r_fullbright 1/0

The work in all video modes. My guess is go into your map and go to the console and type deathmatch and hit enter. If it returns 'deathmatch 1' that means you're running in deathmatch mode and r_draworder or r_drawflat will not work. So make sure when you start your map that you are running a single-player game to see these commands in action. Another great command is 'developer 1' The game ships by default to this turned off so the player doesn't see any messages while playing (plus in script we've put in a lot of test messages that you'd be seeing other wise, ya know, things like 'dumb piece of shit variable one value currently is: X" type stuff http://www.ritualistic.com/ubb/images/icons/smile.gif. So by turning this on to one, you should see any errors your map might be causing.

You know what r_draworder does, but another great command is r_drawflat. What this does is show all the bsp splits in the level. So you can see where a lot of splitting is occuring and where some problem areas are.

And lastly r_fullbright just turns all light in the level to max.

Some important things to note, especially for single player levels but in deathmatch as well. Do NOT disregard epoly count, this can affect your framerate worse than wpoly count. There needs to be a balance. Epoly's take a more CPU time to calculate, so you have to keep them in consideration. For example, I could have an area in a map with say, 500 wpolys, but I have 7000 epolys. I will get non desireable framerate (I'm also running on a PII-300 with 128 MB or RAM, and a VooDoo2).

The epoly consists of all the a-models in the game (baddies, items, anything that you'd build in say 3D Studio Max or Lightwav http://www.ritualistic.com/ubb/images/icons/smile.gif. The epoly count does NOT include b-models (func_doors, func_scriptobjects, etc....). So to give you a deathmatch example, you build a room to 500 wpoly's and think yer fine right? Well the Blade player model is approx 700 epoly's. Plus you have to count the weapon model. One of the higher epoly weapon models is the Rocket Launcher (it's approx. 300 epolys, and the rest of the weapons average around 200 - 250). So right there one Blade with an RL is 1000 epolys. That's also not including your view model (the actual gun in your view), and those range from 400 to close to 1000. So 4 blades with rocket launchers alone 4000, plus the persons view model. And we haven't even counted in yet all the other items, like weapons sitting in the world, health, ammo, the actual rockets and effects that fly across the screen, etc... It can add up pretty quickly.

So yes wpoly count is very important, but you definately need to consider the epoly count as well. Sticking to around 500 wpoly's is a good number, but that should be your max limit in the extreme corners. A good rule is to check your wpoly count in the corners of yer map where you can see the most in any area, this way your maximum wpoly count is in those extremities and when players are walking around in the central areas, the wpoly count will be less. If you aim for say 500 wpolys in the center of the room, then they will be fairly higher on the outter edges.

Also, here's another neat trick we did to pull off larger areas. If you scale a texture up, it increases it's default bsp split size. So if you have surfaces in your map that are just flat walls with nothing intersecting those walls, look at them in r_drawflat and you'll see how much they get split. If you scale the texture up on that surface, you can reduce the number of splits. The down side to this is that it can cause QRAD lighting problems in some areas. Plus don't go crazy with the scaling, just by going simply to a 2 or 3 times scale is more than enough to help the area. Something to play around with and get a feel for. But this will only work when scaling up. The opposite will happen if you scale them down (as in you'll get more bsp splits....bad http://www.ritualistic.com/ubb/images/icons/smile.gif.

Well, hope this helps a bit, sorry for the long post http://www.ritualistic.com/ubb/images/icons/smile.gif.

Latuh fuh U,
"Humor is the wine of funny, not the vinegar of dumb."

02-25-1999, 12:52 AM
Thanks again for all this cool info and clarifications on what epoly count really implies.

I didn't know about not being able to use r_drawflat and r_draworder in DM mode, I'm sure Tatu will be happy to read this http://www.ritualistic.com/ubb/images/icons/smile.gif

(he's been looking for the answer for a while now)

Just a few questions about the above:

1. About epoly count, is there a figure of thumb that we can use to rely on for a "not to be exceeded maximum" ?

2. Did you guys use hint brushes at all to reduce poly count in troublesome areas? If so, often? Not often? It's be nice to read some comments from the pro's about the use of hint brushes.

The Node
www.ritualistic.com/node (http://www.ritualistic.com/node)

The official Sin entities and scripting reference site

02-25-1999, 01:54 AM
As far as epolys go it's a give and take with wpolys and the scene yer in. If you have a relatively high wpoly scene, then try to make sure there's less epolys in the area, and vice versa.

If you're designing for DM maps then I'd say go into a server and run around for a while with r_speeds turned on and check out the numbers. When you begin to notice any kind of a frame rate hit, take a look at the epolys and wpolys and try get an average of what's good and what's not. The ideal goal for the single player as a balance was like 500 - 600 wpolys with about 2500 - 3000 epoly's to keep the framerate decent (this was the average, but of course we varied off and around this a lot http://www.ritualistic.com/ubb/images/icons/smile.gif. In deathmatch, we'd pretty much just try to keep the weapons out from the big open areas where everyone can see into. 2015dm1 is a good example of this. Zied moved most of the high epoly weapons out into the outter hallways so you can't really see them as much when looking into or around the big center area. Of course whenever you have a big area where lots of people can go into your going to have epoly problems because there's no certain way to predict where people are going to be when they're fighting.

As for hint brushes, pretty much I'd design a level out on paper (a rough top down sketch) and try to connect everything in the best way I could that would be good vis-blocking structure, yet not be too conveluted that it wouldn't look like what I was going for. Then I'd use the hint brushes to tweak the areas that didn't seem to want to behaive. Pretty much when I did poly count checks, if there was an area that was a little high I'd turn on r_draworder and see where it's vis'ing too. If it's going somewhere I don't want, then I'd use the hint-brushes to tweak that (if possible). It takes a little getting used to, but once you understand the basic principles of how vis works, hint brushes become a snap http://www.ritualistic.com/ubb/images/icons/smile.gif. It's really hard to explain here without a diagram to show actually http://www.ritualistic.com/ubb/images/icons/frown.gif.

Hope this helps a bit http://www.ritualistic.com/ubb/images/icons/smile.gif.

Latuh fuh U,
"Humor is the wine of funny, not the vinegar of dumb."

02-25-1999, 04:38 AM
http://www.ritualistic.com/ubb/images/icons/smile.gif this answerd my r_draworder prob, now i can use it http://www.ritualistic.com/ubb/images/icons/smile.gif thx for help guys

Tatuone &lt;TF&gt;
visit our site at