irishpump Posted February 23, 2003 Share Posted February 23, 2003 Lighting is practically the most important part of mapping. Anybody can toss textures onto caulked brushes. Its lighting that can make realistic, and spectacular effects. But ive noticed that lighting really bogs down on framerate. When i was mapping for mohaa this was never an issue but with jk2 im noticing that lighting has a dramatic effect on fps. Right now im using regular lights, and colored lights. Im not using any styled lights at the moment (blinking, fluroescent, flicker). Does anyone have any tips on possibilities around this? One other question to go along with this is it better to have one light with a radius of 300 then to have 2 lights with a radius of say 75? Because it seems like the more light entities the more bog down on fps, and that light radius doesnt play as big as a role as the actual entity? Link to comment Share on other sites More sharing options...
DigitalVapor Posted February 24, 2003 Share Posted February 24, 2003 Well, While one light may be faster than 2 you must consider that to have realism you must make sure you stay faithful to your lightsource. You cant for example have a room with a wraparound second floor and light it realisticaly by using one light in the middle. You need believable lights and lightsources. Another example is when using somthing like a fire fx_runner, you should naturaly add a yellow-orange light with an intensity of about 10 to get a realistic lighting effect. So when realism matters, You cant escape the lighting times. Also if you can get away with it you might try using light emitting shaders like kejim/flatwhite. I once lit an entire cantina using ONLY that shader. it made for a dim but believably lit environment suitable for a bar scene Link to comment Share on other sites More sharing options...
irishpump Posted February 24, 2003 Author Share Posted February 24, 2003 Realism isnt the problem. I think this will explain a little bit better here i posted a couple pics of 2 of 8 buildings im working on. I hate to show what im working on because theres just something about keeping your work hush hush until the finished product. You can see the fps in the corner sitting at about 50 and in regular jk2 maps i get fps on average of 180-200. All brushes are detailed, caulk being used. It is big though. Anyway you can check it out here: http://myweb.cableone.net/irishpump/default.htm Let me know if you see something that i might beable to do to lower the fps. Link to comment Share on other sites More sharing options...
Leslie Judge Posted February 24, 2003 Share Posted February 24, 2003 I think you should make a test to see how high would be the FPS when you use fewer light entities. Personally I think the number of the light entites doesn't make anything with the FPS, since lighting is calculated compile time. There are the same number of lightmaps if you use only one light with big scale or two light with smaller scale. It depends more likely on how many surfaces the engine has to draw. In MP the r_showtris command doesn't work, but you can check r_speeds, or use cg_lockpvs 1 (I'm not sure this is the right syntax of the command) to see what is drawn in your map. Link to comment Share on other sites More sharing options...
irishpump Posted February 24, 2003 Author Share Posted February 24, 2003 I did quite a bit of playing around with light intensity and removed about 8 light entities and it increased fps by 15-20 in all spots. In fact the intensity made the lights even more illumanted without bogging the fps. So it was the amount of light entities that will start to make the frames deteriote. Just something to add to the list of things to watch out for when making maps for jk2. Link to comment Share on other sites More sharing options...
Leslie Judge Posted February 24, 2003 Share Posted February 24, 2003 Hmm... quite interesting. Never thought. Did you try this with q3map2 2.3.36 or later? In those versions the light entities are no more stored in the bsp file. I'm just curious. Link to comment Share on other sites More sharing options...
irishpump Posted February 24, 2003 Author Share Posted February 24, 2003 No actually i used jk2radient because when i went to compile with gtk radient it went fast but it took all my lighting out and made the ambient light fullblasted bright. I guess i just got used to jk2radient. That sounds interesting to not have the lighting in the actual bsp. If you could explain a little more on this i might be persuaded to switch back to gtk compiler. Link to comment Share on other sites More sharing options...
wedge2211 Posted February 24, 2003 Share Posted February 24, 2003 "fullblasted bright?" Which Gtkradiant compile option did you use? The only real difference between lighting as calculated by SOF2MAP versus q3map2 is that the q3map2 lighting is often darker. Are you sure you picked a q3map2 compile that went through the lighting phase, or that you don't have any leaks (causeing a fullbright error?) Generally speaking, q3map2 is far superior to SOF2MAP (including the light phase of compiles), so I'd check to make sure the compiles are running smoothly. As Leslie said, I think all lighting information (well, not dynamic lights) is calculated at compile time. Hmm. Link to comment Share on other sites More sharing options...
Leslie Judge Posted February 24, 2003 Share Posted February 24, 2003 Yeah, in GtkRadiant the q3map2 options starting with (single) are not full 3 phase compiles. They just run only one phase. On the top of the list, where you can see (test) or (final) in front of the option are the full compiles. What you say about "fullblasted bright" is probably because you started a simple BSP with no lighting (nor vis I guess) after it. But wedge is right about that q3map2 makes lighting a bit darker than sof2map. This is because everyone uses the -fast option in lighting phase. But without -fast what would be the point of q3map2? What I said is that light entities aren't stored in the bsp file, because they aren't necessary in game. For static lights the casted lights and shadows are calculated in compile time (that's why it can take so long), and the generated lightmaps are stored in the bsp file. This is good, because if you change the position, number or parameters of light entities you don't have to rerun the BSP or VIS phases again, since the LIGHT phase will read all the lighting information from the map file directly. Link to comment Share on other sites More sharing options...
ydnar Posted February 24, 2003 Share Posted February 24, 2003 The -fast option enables limits on how far surfacelights can cast light, similar to the limits all Q3Maps have had on entity lights. That said, there are plenty of differences in the lighting. Better differences, like detail brushes not causing dark seams. Lightfiltering. Adaptive antialiasing. Filtering. Radiosity. Baking cookies. The same. Hah! y Link to comment Share on other sites More sharing options...
irishpump Posted February 24, 2003 Author Share Posted February 24, 2003 Yeah i just realized ive got 2 leaks that i need to fix Link to comment Share on other sites More sharing options...
yangyan Posted February 25, 2003 Share Posted February 25, 2003 My first map http://www.pcgamemods.com Oh i used loads i mean loads of lights and Framerate went wheee and my map SuCkS BeCaUsE oF ThE lIgHtS. Link to comment Share on other sites More sharing options...
lauser Posted March 19, 2003 Share Posted March 19, 2003 Hey guys...I usually use FuLL bsp to do compiles. So I had the FULL intensity light in my map a few times already. And every time it was because I had a good sized leak. Fixed the leak, then restart JK2Radiant and do another BSP. Fixed... Anyone know how I can improve my FPS? Yes it's probably in the forums here somewhere. I guess I'll have to keep looking. What does the Area Portal texture do? You know the big Yellow one? I know I'm supposed to use it but how? Also I guess I should run CLIP throughout my map to smooth out the sparklies? There are a lot of uneven angles in my map that are hard to line up sometimes, so I end up overlapping some brushes to fix a leak. Is that bad? Link to comment Share on other sites More sharing options...
ioshee Posted March 19, 2003 Share Posted March 19, 2003 Originally posted by lauser ...There are a lot of uneven angles in my map that are hard to line up sometimes, so I end up overlapping some brushes to fix a leak. Is that bad? Yes. I can't think of any reason (visible) brushes should EVER overlap in your finished map. Take out your clippers and clip away. Clipy clip clip Link to comment Share on other sites More sharing options...
wedge2211 Posted March 19, 2003 Share Posted March 19, 2003 Clip shader doesn't do anything for sparklies, it just makes a solid but invisible brush. Link to comment Share on other sites More sharing options...
ioshee Posted March 19, 2003 Share Posted March 19, 2003 Sorry, wrong syntax. I meant use the TRIM tool. You know the one that cuts brushes. It's just that I'm retarted. Sorry. Link to comment Share on other sites More sharing options...
Leslie Judge Posted March 19, 2003 Share Posted March 19, 2003 Hehh, ioshee, actually that is called CLIP TOOL, so you was right when used that word. Link to comment Share on other sites More sharing options...
wedge2211 Posted March 19, 2003 Share Posted March 19, 2003 I was referring to this: Originally posted by lauser Also I guess I should run CLIP throughout my map to smooth out the sparklies? Link to comment Share on other sites More sharing options...
lauser Posted March 20, 2003 Share Posted March 20, 2003 OK guys, I don't mean the NO physics Clip shader I mean the CLIP shader! What is the difference? Also the Area Portal shader is used for sectioning leafnodes correct? I made a brush and put it in a hallway sectioning off another large area of my map. Then I used the Area Portal to cover it. This is supposed to improve my framerate so I'll try a BSP now. Is Area Portal a hint brush? Link to comment Share on other sites More sharing options...
ioshee Posted March 20, 2003 Share Posted March 20, 2003 The difference between the clip shader and the physics_clip shader is that when you hit the physics_clip one with a weapon, it stops your weapon. The regular clip shader lets laser bolts, sabers, rockets and such pass right through. BOTH of them block players. So you would use physics for models, but regular clip for stuff like building an invisible ramp up stairs (because the stairs themselves will block the laser bolts.) As a general rule, area portal is used inside doors (because the vis process doesn’t see doors) and hint brushes are used in halls where there is no door for the same purpose: to create more leaf nodes. Link to comment Share on other sites More sharing options...
wedge2211 Posted March 20, 2003 Share Posted March 20, 2003 Originally posted by lauser Also the Area Portal shader is used for sectioning leafnodes correct? I made a brush and put it in a hallway sectioning off another large area of my map. Then I used the Area Portal to cover it. This is supposed to improve my framerate so I'll try a BSP now. Is Area Portal a hint brush? Nono, ioshee is right, areaportal goes inside doors. If you use q3map2, then you need to texture a brush with common/skip (included with q3map2) and then put areaportal on ONE face. Hint brushes are hint brushes. They cause a leaf-node split. Note that this doesn't increase frame rate if you place them improperly...the engine will still draw everything on the other side of the hint brush unless that leaf node is blocked from view entirely. There's a good tutorial on hint brushes somewhere out there, but I forget the link, do a search. Link to comment Share on other sites More sharing options...
Leslie Judge Posted March 20, 2003 Share Posted March 20, 2003 http://www.nibsworld.com/rtcw/tutorial_detail_and_hint_brushes_part1.shtml Link to comment Share on other sites More sharing options...
Recommended Posts
Archived
This topic is now archived and is closed to further replies.