Announcement

Collapse
No announcement yet.

FTE, and Lightmapping with Quake 3 format BSP

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • FTE, and Lightmapping with Quake 3 format BSP

    I'm really confused on something and I can't think of a better place to ask. It's probably one of those "common knowledge" bits that people passed around over IRC or something years ago but never wrote it down. I have been working on a large project for a while and I am using FTE with Quake 3 format BSPs. I have a functional map as far as gamecode working is concerned but when I try to compile the map with lights and I open it in FTE it says there are no lights detected. Is there any reason for this? Should I be using some other compiler? Is it an engine issue that requires some other workaround? Any help would be appreciated, as this is the last major problem in the way that keeps workflow from going into full force.


    Error here:


    Compile options I have tried:
    Quake is for nerds.

  • #2
    the map seems fullbrighted, so there is two options
    1- bad light stage compilation (try compiling light stages by hand, with bats or something)
    2- bad FTE's config ( try the map with another engine like darkplaces)


    normal q3bsp doesnt work with "light entities", and norrmal q3bsp doesnt support lightstyles!
    FTE is not detecting "light" entities
    if you want to keep the lights you must set in worldspawn
    _keeplights 1


    aniway, FTE support FBSP, i suggest you use FBSP because lightstyles and high quality.

    Salu2
    the invasion has begun! hide your children, grab the guns, and pack sandwiches.

    syluxman2803

    Comment


    • #3
      Originally posted by nahuel View Post
      normal q3bsp doesnt work with "light entities", and norrmal q3bsp doesnt support lightstyles!
      FTE is not detecting "light" entities
      if you want to keep the lights you must set in worldspawn
      _keeplights 1
      Salu2
      What do you mean when you say it doesn't work with light entities? Do I need a separate compiler? What will this flag do when I set it?
      The biggest question really is how should I be compiling these maps to not only work, but also allow maximum potential functionality?

      On an unrelated note, is there a place I can find documentation on lightstyles? It seems like a feature that is quite nice.

      Originally posted by nahuel View Post
      aniway, FTE support FBSP, i suggest you use FBSP because lightstyles and high quality.
      Salu2
      I'm not sure what this is. Upon research it seems like it is an improved BSP format that Warsow uses. Can I get an explanation on this?

      Also do note that I am explicitly using Quake 3's map format to take advantage of RGB textures. The rest of it is reliant on Quake C and related Quake 1 logic.
      Quake is for nerds.

      Comment


      • #4
        make sure your map does actually contain some light entities somewhere.

        q3map2 strips out light entities. use -keeplights (or apparently that worldspawn key) if you wish to keep them for use with r_shadow_realtime_world. failure to do so will result in r_shadow_realtime_world_lightmaps getting internally forced to 1 along with that print, if its not already 1 (so you see lightmaps that q3map2 baked in).

        I don't know which game you've got radiant trying to target. many game targets use external lightmaps as this is a way around q3bsp's limited lightmap size, so make sure that they're also in the right place as well as just the bsp. Use of FBSP should also bypass this.

        Alternatively csaddon has an rtlights editor that will make importing lights from the bsp redundant, and exposes a few more twiddles.
        Some Game Thing

        Comment


        • #5
          lightstyles:
          quake engines support up to 255 different 'styles'. essentially style is a slot within a lookup table that is rebuilt each frame from each style's 'lightstyle' string (which is updated via builtins).
          q1bsp+rbsp(+fbsp) support up to 4 separate lightmaps per surface, each map with its own style.
          q3bsp does not support lightstyles, in that each surface has a single lightmap with no style value. This means vanilla q3 does not support flickering lights or lightswitches etc (although you can use shader tricks to replicate such things, but it gets quite messy).

          fbsp(from qfusion/warsow) is a variant of Rogue Software's 'rbsp' format (from eg the q3-based jediknight games) and thus regains lightstyles, except that fbsp has a larger internal lightmap size (512 vs 12, which gives a slight performance boost.
          Alternatively external lightmap textures provide a way to bypass the formats internal lightmap size, meaning they can be any resolution you want, with png or even dds compression, or really any such trick.
          Some Game Thing

          Comment


          • #6
            Originally posted by Spike View Post
            make sure your map does actually contain some light entities somewhere.
            It most certainly does.
            Originally posted by Spike View Post
            q3map2 strips out light entities. use -keeplights (or apparently that worldspawn key) if you wish to keep them for use with r_shadow_realtime_world. failure to do so will result in r_shadow_realtime_world_lightmaps getting internally forced to 1 along with that print, if its not already 1 (so you see lightmaps that q3map2 baked in).
            I see.
            Originally posted by Spike View Post
            don't know which game you've got radiant trying to target. many game targets use external lightmaps as this is a way around q3bsp's limited lightmap size, so make sure that they're also in the right place as well as just the bsp. Use of FBSP should also bypass this.
            What exactly is FBSP? So far I understand that it's an alternate format with extended capabilities, but does it have it's own optimal compiler? It also appears that q3map2 supports exporting of it.
            It's targeted at a "Quake III modification." Should I be using another profile? On another note, would anyone know how to make a custom Radiant profile?
            Originally posted by Spike View Post
            Alternatively csaddon has an rtlights editor that will make importing lights from the bsp redundant, and exposes a few more twiddles.
            I am interested in using realtime lights instead if the performance isn't too terrible. I'd like to put considerable effort in with that department. The question is how intensive it would be. This is a multiplayer modification so ludicrously high requirements are not ideal.
            Last edited by Ebisu; 12-29-2016, 09:56 AM.
            Quake is for nerds.

            Comment


            • #7
              you can try compile your map using this tutorial and quark

              https://www.warsow.net/wiki/Mapping
              the invasion has begun! hide your children, grab the guns, and pack sandwiches.

              syluxman2803

              Comment


              • #8
                Originally posted by Ebisu View Post
                What do you mean when you say it doesn't work with light entities? Do I need a separate compiler? What will this flag do when I set it?
                The biggest question really is how should I be compiling these maps to not only work, but also allow maximum potential functionality?

                On an unrelated note, is there a place I can find documentation on lightstyles? It seems like a feature that is quite nice.


                I'm not sure what this is. Upon research it seems like it is an improved BSP format that Warsow uses. Can I get an explanation on this?

                Also do note that I am explicitly using Quake 3's map format to take advantage of RGB textures. The rest of it is reliant on Quake C and related Quake 1 logic.
                if you look performance use lightstyles instead real time lights! lighstyles, lightstyle affect the lightmap, a light with lightstyle is not a real time light : for example, in quake 1 a torch is not static light, there is some brightness variations, example 2: if you want to turn off a light, the light will have a lightstyle to change the intensity to 0 etc... in quake 3 arena you do not have switcheable ligths or light with brightness variations like quake 1 or quake 2. FBSP is (like spike said) a q3bsp with lightstyles support


                you can change the values of different lightstyles via qc


                In an engine where the game logic is qc based like darkplaces a normal q3bsp has all the lights with "lightstyle" = 0.
                you can change the values of different lightstyles via qc
                in world.qc you will find

                // 0 normal
                lightstyle(0, "m");
                so if you change to this
                lightstyle(0, "masjhdfkjhlakshgfhsajkghlkjsdfg")
                the entire map will have a strange light variationwhere "z" is the maximun ammount of light intensity and "a" is the minimun , so "a" is darkness.


                i think q3bsp is great because deluxemapping, easy managment of textures and shaders and beziers. The only disadvantage is the lack of lightstyles, but FBSP solves the problem
                Last edited by nahuel; 12-29-2016, 10:13 AM.
                the invasion has begun! hide your children, grab the guns, and pack sandwiches.

                syluxman2803

                Comment


                • #9
                  Heeeeey Ebisu, long time no see....

                  @but does it have it's own optimal compiler?
                  You use the q3map2 compiler by Ydnar to make FBSP maps.

                  @Should I be using another profile?
                  use -game qfusion on the q3map2 command line to create FBSP maps

                  That info is from a PM that golden_boy sent me years ago in regards to questions I asked him. ie... golden_boy just answered your questions. However, I kept my promise...

                  "I promise that any knowledge that you bestow upon me, I will turn right back around and teach it to anyone that cares to learn. ~ gypsy"

                  @would anyone know how to make a custom Radiant profile?
                  I know this guy that knows everything about doing exactly that. If you asked him real nice he would probably hook you up. Although, you could probably just use the darkplaces gamepack and change the engine to FTE. There really isn't much "darkplaces" about the DP gamepack other than it points to DP home on linux, mac and win. For the change part of the image below you can delete or leave alone most of that. Just make sure you correct the details that refer to your OS.



                  NOTE: If you change basegame in the darkplaces.game FILE you will also have to change the name of the game folder inside the darkplaces.game FOLDER
                  NOTE2: Do you know what makes this a Quake3 gamepack, bro? texturetypes includes tga, modeltypes includes md3, maptype is mapq3, and all those spots where it has a quake3 value. The rest of that is pretty much just a bunch of fluff and you can change it to whatever you want that exists and makes sense. For instance, what if instead of C:/Quake/id1 you had C:/Ebisu/game - just change gamename and basegamename accordingly and go in the darkplaces.game folder and change id1 folder to game folder. See, this shit is super easy. You can change unknowngamename to whatever the hell you want. It is completely useless. Shaders usually go in a scripts folder. You can change that to any folder you want as long as it exists !!BUT!! the engine might not (read ~ probably wont) like you for it.

                  ABOUT THE BUILD MENU:
                  The build menu is nothing more than an xml version of your command line. If you see something like
                  <var name="q3map2">"[RadiantPath]q3map2.[ExecutableType]" -v<cond value="[MonitorAddress]"> -connect [MonitorAddress]</cond> -game quake3 -fs_basepath "[EnginePath]"<cond value="[GameName]"> -fs_game [GameName]</cond></var>

                  all that is doing is concocting a command line and storing it all in a var named q3map2. That means that ALL of that is now represented with the token [q3map2]. RadiantPath, ExecutableType & MonitorAddress are built in to radiant and will be whatever they need to be based on where radiant is, what OS you are on and whether or not you have BuildProcessMonitoring on. EnginePath and GameName are determined in the .game file. So, when you go to do actual map compiling you can do this

                  [q3map2] -vis "[MapFile]"

                  which would expand to something like this on the command line ~ gist

                  radiant/path/actual/q3map2.exe -v -game quake3 -fs_basepath engine/path/actual/yourGame -fs_game yourGame -vis theMap

                  If you want a solid build menu just work backwards. Write out your command line as normal, token the things that are built in tokens, find the parts that will never change and make them a var and then reconstruct as

                  [varToken] -changingPart "[MapFile]"

                  Let's make an example with something you are more familiar with
                  fteqw.exe -game rogue +map r1m1

                  let's pretend you told radiant where fteqw is in your .game file
                  <var name="cmdLineExample">[EnginePath] -game rogue +map</var>

                  <build name="Run Rogue Map">
                  <command>[cmdLineExample] "r1m1"</command>
                  </build>

                  This would appear in radiant under the "Build" drop down as "Run Rogue Map" and, upon being clicked, would load r1m1 in fteqw. assuming of course that you had rogue "installed" ....etc.

                  PROTIP: If you are using NetRadiant, make a folder in the NetRadiant root directory named "settings" and start Netradiant. Now all your stuff like junk.txt and various other config stuff is in the settings folder you created instead of C:/Users/You/AppData/Local....etc. This feature is only available on NetRadiant. It also means that you can drag and drop NetRadiant anywhere you want, even onto any computer with the same OS, and as long as all your engine/game directories are the same you're good to go. ie... you just made NetRadiant portable.

                  --------------

                  edit: here is pretty much the rest of that PM from golden__boy, in case there is something in here that can help you

                  http://en.wikibooks.org/wiki/Q3Map2

                  Note that some entities work differently with q3map2; for example misc_model does something special (models are actually compiled into the BSP), and lights have spawnflags and different keys than in Q1, and spotlights always require targeting an info_(not)null. Sunlight and ambient light are also done differently (via sky shader, and via floodlight feature).

                  2) You use Radiant to make maps for FBSP; you start with the Darkplaces gamepack because that uses TGA images and shaders (Quake 3 does not use texture wads). You run Radiant in Quake 3 mode so the maps get saved as Q3 .map format (yes the map format is different too). This mode allows you to use shaders, curves, patch meshes etc.

                  You modify the DP gamepack's config files to contain your engine path etc, and work with the model formats you want. You must also configure it to use your entity .def file, not the default one.

                  To use shaders, you must install a couple things; chiefly, you need a scripts folder in your mod's gamedir and inside you have the common shaders (trigger, clip, hint, nodraw, origin, caulk etc). These common shaders come from Quake 3 in a file called common.shader. You probably also want sky, water, glass etc. shaders. You can get them from the web, from games like Warsow, and from Quake 3 itself.

                  Inside the scripts folder is a shaderlist.txt file that just lists the names of the shaders to be loaded.

                  You also want the corresponding images for the shaders to use in the editor; these go in the textures/ subfolder. Radiant will display a white frame around an image in the texture browser IF a shader belongs to that image.

                  All your TGA textures (I use Moondrunk's textures as a base) also go into textures/ so Radiant will find them. You can directly use TGA images for mapping - no more texture wads. You need to scale them down in the surface editor to fit the Quake scale, usually the scale factor is 0.125. This is because their resolution is so much higher than Quake's.

                  Q3map2 supports deluxemapping; this means you *can* use normalmaps with static lighting if the engine supports it. Lumas also work (instead of Quake 1's fullbrights). To use animated textures, you really should use a shader, but FTE at least also supports the old Quake way of animation. For water and sky, you definitely need dedicated shaders.

                  You *can* use GLSL within a Quake 3 shader. For example I use FTE's pretty water in my water shader! Shaders also support if statements to check if eg GLSL is even available.

                  Here is the shader manual that explains the shader syntax:

                  http://q3map2.everyonelookbusy.net/shader_manual/

                  I can also give you shaders if you want.

                  Be aware that Quake 3 shaders are NOT the same as GLSL shaders!!! For example "pretty water" is done with GLSL shaders, while a light emitting texture is done with a Q3A shader. Think of Quake 3 shaders as "materials" similar to Doom 3's. Just read a few examples.

                  Curves and patch meshes will just work as soon as you use the Quake 3 setting in Radiant.


                  //END BOOK ~ lol

                  PS> I maybe would have given you all of this information anyway but, I definitely gave it to you because I never forgot how you stuck up for me after I was banned.
                  Last edited by MadGypsy; 12-29-2016, 03:07 PM. Reason: I am really for real done editing.
                  http://www.nextgenquake.com

                  Comment


                  • #10
                    Originally posted by Ebisu View Post
                    I am interested in using realtime lights instead if the performance isn't too terrible. I'd like to put considerable effort in with that department.
                    Both methods have their pros and cons. Overall, rtlights might be less of a pain and require less fiddling depending on your chosen aesthetic. Maybe use a mix of the two? Maybe just use rlights for lightstyles and use lightmaps for the rest? There is an issue when doing this in darkplaces, I don't know if FTE handles it the same way. Are you using normal maps and such?

                    Originally posted by Ebisu View Post
                    The question is how intensive it would be. This is a multiplayer modification so ludicrously high requirements are not ideal.
                    You will definitely see a performance hit but it *probably* isn't a deal breaker. If you're happy with 60fps on an average machine then I don't think it's an issue. If you want 300fps on a low end machine, well, you don't really have a choice but to go with lightmaps.
                    www.youtube.com/user/KillPixel

                    Comment

                    Working...
                    X