Announcement

Collapse
No announcement yet.

TyrUtils Experiments

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

  • TyrUtils Experiments

    I figured I can't really get away with rewriting an entire ent to reflect modern tools, without creating some examples and experiments with the product of my rewrite. That being said, this first post will regard light and brush keys.

    I would like to add that I don't exactly understand all of which I am going to show you here, and in those cases it's not so much about explaining the feature as it is about realizing the results.

    I would also like to add that, these are experiments and I am not a pro so, the techniques I show you here may not be the best technique to use. It will take someone with more knowledge than I to enlighten you further.

    It is also highly recommended that you use my ent for tyrutils AND the virtuoso game pack. You do not have to use these things but, if you are it will make it much easier to follow this experiment. In the case where you aren't using the recommended set up:

    1) Every time I fill in a value, you will have to manually type the key and value
    2) Every time I compile via the build menu, you will have to have some other system present for compiling using tyrutils
    3) Every time I simply click RUN MAP, you will have to have some manual/other system in place.

    ...And with no further ado, the actual experiment:

    ?Brush Lighting?

    Before you begin, you should create a room, texture it, add an info_player_start and 1 light. Then you should create a brush, texture it, go in face select mode, select a face and change the texture for that face into any texture you want that is not currently in use. Place that brush on the ceiling with the "rogue" texture facing down. This is our template we will be working with.


    REMEMBER: you must add the full qualified path of your wad to the worldspawn entity in the Wad File field. Failure to do so will result in your room being completely black in this example.

    It doesn't have to be anything special, this is just an experiment. You may also notice that I drug the light completely out of the map. This isn't what you would want in a real map. It just makes it easier for us to select it and it's fine for this experiment. Before I go any further I would like to add that the values you need to use will in most cases be different than mine. The chances that our rooms are identical in dimension are very very slim.

    Let's begin with the light. Select the light and press N. This will bring up the entity inspector. If you are using my ent you will notice there are a lot of options. For this experiment we only need a few of them.



    The purpose of this experiment is to light a room with a fair ambiance using only one light. That being said, I chose 400 for my light value because my room is a little big. I may need to change this value but for now it's good enough. Since my room is big I also used a delay of 1 to stretch the attenuation of the light a bit. I want sort of a pale yellow light so I put the values in color that equal a pale yellow. I gave deviance the value of 64 because due to my original experiment this was a good amount of units away from the light source to create a sphere of lights in. If you don't understand this, all of the docs are right there in the entity inspector and you can use them to gain greater understanding. I then chose 16 samples because my earlier experiment looked good breaking my light into this many lights. Finally I used the name of what I referred to earlier as our "rogue" texture as the surface value. This turns that texture into our light (everywhere on the map that that texture appears with the same values you put on this light, which may or may not be good.)

    Now let's move to the light brush. Select it, right click and choose func_wall. The reason I am doing this is simple. I need to make it an entity so I can use more tyrutils possibilities but, I want it to be an entity that has no functions. I don't use func_detail because that has other implications in the compiler.



    Here we only set 2 values. I set minlight to 200 because if we don't the sides of our light will be solid black. I set shadow to 1 because I want this brush to cast shadows on the ceiling.

    You can now select BUILD/TYRUTILS to compile. If you are not using any of my stuff the build commands are as follows.

    qbsp.exe mapname
    vis.exe -fast -threads NUM mapname
    light.exe -extra4 -soft -dirty -threads NUM mapname


    I had to turn my light down to 200 and move my deviance up to 128 but, as you can see, whereas not awesome, this is workable. More tweaking between light, deviance and samples could probably make this look pretty good. The light itself (actual texture) looks kind of hot. This could easily be fixed by simply editing the light (texture) to not be so white. Backing off the delay and changing light,deviance,samples may also work. There may even be a way to include another light and implement shadowself. Notice how the minlight setting kept the sides of our light pretty dark but it isn't straight up black.



    Anyway, the point of this experiment wasn't to show you how to professionally light a map or anything. The point was to introduce you to some of the new features in the tyrutils compilers and give you ideas on how you can creatively accomplish certain goals. You should play with the settings more. Build another room and dump a copy of your func_wall in it. Rotate the light to go on a wall. Attempt to gel your values so both rooms look good with just the conglomeration of your one light.

    The main point is to simply enjoy what you are doing.

    Peace.
    Last edited by MadGypsy; 05-11-2015, 09:31 PM.
    http://www.nextgenquake.com

  • #2
    I didn't even know about Tyrutils till about 2 weeks ago. Son of a bitch this is cool. I didn't think a whole lot of it till this example.

    I used to use very soft lighting all around my actual light brushes to prevent the sides from being black. So each light brush had like 5 associated light entities to them. Pain in the ass.

    I'm curious to see what the angle props do. Do they skew the lighting? Can you make true conical lighting now, like spotlights that shine down a wall? This makes me want to get back to mapping something fierce. Still modeling in Blender mostly though.
    'Replacement Player Models' Project

    Comment


    • #3
      Back when I was doing maps, I switched to Tyr's, and it was quite an improvement in lighting. I could put a minimum light level and use a lot less entities, and -soft was great, too. I did not know about these other features, which are interesting, but I don't think I'll be making maps any time soon. But, at least, I'll think about them if the time comes.

      Comment


      • #4
        Experiment Oversight:

        Simply playing with _surface_offset (which is right under _surface in the ent inspector pbbbbbbbbbt) pulls the light away from the surface and easily makes the texture less hot. I actually feel stupid for not engaging this very obvious feature.


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

        @I'm curious to see what the angle props do. Do they skew the lighting? Can you make true conical lighting now, like spotlights that shine down a wall?

        The docs are in the entity inspector. :snicker::hint-hint:

        @Zop - aren't you the guy that bigifies maps? I hope I'm not confusing you with someone else, it's hard to keep track of all the different people and what they do here.

        If you are that guy. You should take one of your big maps and add a bunch of dirt. All you have to do is add one extra switch to the light compile line. light.exe -dirty

        Of course it can be made far more complicating than that, like telling specific things not to be dirty (among other things).
        http://www.nextgenquake.com

        Comment


        • #5
          Another simple experiment

          I have another experiment but, instead of writing a wall o' text about it. I decided it's much easier to simply give you the project files.

          All you have to do is DL the project files, unzip it and drop QRad in C:\ (if you are using my gamepack and .ent, otherwise, disregard this entire thread.). When asked to overwrite, click yes. The only real overwrite that is going to happen is IF you have id.wad in your virtuoso folder, the one in this package will overwrite it, which is a nothing unless you have customized id.wad in some way.

          I know my "fence texture" is total garbage. This is not meant to be a game ready thing, it is just an example. I spent a whopping 5 minutes on that texture. I also included the mip for it in the virtuoso folder, in case anyone wanted to open it in wally and edit it. I didn't feel like searching the quaddicted wad archives for a {fence so I just spun my own real quick (and learned all of wally in the process...fun little program)

          Another thing to note is not all engines support {texturename textures. I'm using fteqw from now on. I have had the best success with things working straight "out of the box" with this engine so, this is my engine of choice. If you follow my experiments and they are not working for you, get fteqw.

          Anyway, obviously the point of this experiment was to audit the _shadow feature of TyrUtils. To speed along your discoveries in the project, I will tell you that the brush with the fence texture is a func_wall with _shadow 1 on it. That's pretty much it. This combination casts shadows as if the "fence" texture was an actual fence with light shining through it. Worldspawn has some simple sun keys set but that really wasn't the point of this experiment, beyond making enough light to make the effect obvious.

          re: I know this looks like shit.


          sources of information that I used:
          How to make an alpha masked texture - golden_boy - about 85% of the way down the page

          PS> The name of the map is sun.map. I don't know why I called it that. That name has nothing to do with this example.
          Last edited by MadGypsy; 05-12-2015, 07:28 PM. Reason: linking this post up...lol
          http://www.nextgenquake.com

          Comment


          • #6
            Observations regarding surface lights:

            If you are going to use _surface to create ground lights here are some things to consider:

            For every repetition of the texture, the light values that you attached to that texture will be repeated. This has some serious implications. For one, using deviance and samples is totally dumb in this case. You are already going to have 1 light for every repetition of the texture, breaking that light up into more lights that are arranged in a sphere, which is potentially bigger than the actual texture, is stupid.

            Another thing to consider is, a brush has 6 sides but, you are only going to be walking on one of them. This means there are 5 (potentially unseen) sides of that brush which will have lights attached to them. It does not take long, at all, before this dramatically increases your compile times. All for something that you are never even going to see.

            The work around for this is to create your brush with some other texture, go in face select mode, select the face that will be the actual ground, and apply the surface light texture to just that face. In the case where the floor is broken up (maybe due to a pool or lava pit), making it to where you can see sides of the brush that do not match the floor, simply trim it out. You would probably want to trim out such a thing anyway.


            This screenshot is an experiment using just 2 lights to light the entire room. There is sunlight as well but all that is doing is drawing a box of light on the floor to make it more interesting. 1 light is attached to the floor texture and is colored roughly the same color as the sky. The other light is attached to the lava and is colored roughly the same color as lava.


            But lets take a look further at what you can't see.


            All I did to encase the lava was drag my floor brushes down making them longer (and of course capped the bottom of the lava) BUT notice the texture is not the floor texture. This is congruent with what I said earlier. I don't want 600 million lights on the outside of my map. Could you imagine how long it would take to compile all those useless lights? This is also why I trimmed the lavapit. Without the trim you would be able to see that the floor abruptly becomes some other texture.

            Now let's talk about something else. I have a light every 64 units across the floor, due to how surface lights array themself for each repetition of the texture (and my texture being 64x64). My room is quite large (1024 x 1024), which means I have (1024/64)^2 lights. My light brightness value is 9. When cheating and doing it this way your lights have to be practically off. I also have quite a large _surface_offset to get the lights to have some effect on the ceiling.

            It would probably be worth the effort to take the floor texture into an editor and quadruple it's size by making it 2x2 (or even bigger) and then making that the texture in the wad. It would dramatically decrease the amount of lights created and allow more control at brighter light levels.

            note: I realize my lava pit doesn't have to be even deeper than the room is tall. This is quickie stuff for the purpose of my various experiments and none of what I post here should be considered an actual attempt to make a map. I also realize that it isn't even very good. Well, that's because I'm not very good but, the things I'm telling you here are rock solid.
            Last edited by MadGypsy; 05-12-2015, 09:59 PM.
            http://www.nextgenquake.com

            Comment


            • #7
              I'm wrong, changing the size of the texture does not decrease the lights. I think I know what does but I need to do some more tests. Apparently there is some other algorithm being used than textureRepetitions = lightCount.
              http://www.nextgenquake.com

              Comment


              • #8
                I think I figured it out. The amount of lights is based on QBSP -subdivide switch

                -subdivide 120


                -subdivide 240 (default)


                -subdivide 480


                In the case of 120 I am getting what I expect, more subdivision = more light (than default 240). In the case of 480 I don't understand what is going on. It almost looks like a weird fullbright. Due to the size of my room a subdivision of 480 is like 4 lights(ish) I would expect it to be really dark but maybe that number has other implications beyond just the light count. Maybe that number has nothing to do with the light count. In the first 2 examples it sure seems like it though.

                Of course I am also assuming that the -subdivide value is when the next subdivision will occur, not how many subdivisions will be made. I think this assumption is validated by the fact that -subdivide 120 takes a long time to compile, -subdivide 240 is meh not as long as 120 but still not very fast, -subdivide 480 is so fast my cmd shell practically disappears the second light.exe is hit.

                My current "map" is sort of a combination of all the tests I have been running. I added some bullshit buttresses to play with dirtgain and other dirt modifiers, just to see what kind of results I would get. My grate over the lavapit is of course just a lil thing I did to play with alpha masking and see if I could get shadows on the lava (so far no luck), and the floor is lighting the entire room, hence my ground light test. I know it's not awesome but I kinda like the look of the -subdivide 240 image. I've definitely seen worse. I've definitely made worse. I know it's pretty dark but that's exactly what I would expect from a large room that is being lit by some moonlight being squeezed through a skylight and some glow from the lava. Actually, It's probably still too bright. Tomorrow I will add some wall lights and see if the ambient brightness from the surface lights can be made more realistic. If I could ever figure out how to make some decent lights, I could probably make a decent map.

                I'm gonna run one more test cause I think I understand why -subdivide 480 is so weird.
                Last edited by MadGypsy; 05-13-2015, 12:29 AM.
                http://www.nextgenquake.com

                Comment


                • #9
                  Well, I ran my test and I got the exact same results. I was thinking that with so little subdivisions maybe sunlight was getting spread all over the place somehow, however, I removed all the sun and the results were identical. Since I can't figure out the 480 anomaly I will leave you with another unrelated tidbit of info.

                  the qbsp -wadpath switch allows you to define the directory for your wad files. This means (if defined) all you have to write are the wad file names in worldspawn.

                  example:

                  qbsp.exe -wadpath C:\QRad\Quake\Virtuoso\ MapName

                  and then in worldspawn wad file field [wad1.wad;wad2.wad;wad3.wad]

                  If this doesn't work for you try putting the path in quotes

                  qbsp.exe -wadpath "C:\QRad\Quake\Virtuoso\" MapName
                  and/or try this
                  qbsp.exe -wadpath "C:/QRad/Quake/Virtuoso/" MapName

                  it really depends on how you are calling your build commands. In a standard bat the very first one should work. In radiant the very last one should work. I just made up the middle one BUT if you have spaces in your path and you are using a bat, the middle one would be right. You should never have spaces in your path though, it's dirty and unfriendly.


                  -----

                  Side note: Spike was kind enough to give me a generic example on how to write a QC class. I totally get it now and soonish I will be tutorializing that too. I've wanted to sink my teeth into it for quite a while but, I never could figure out where to begin. I know where to begin now. I know where to end too, a completely rewritten, from the ground up, source. I'll make it happen, you just have to wait. I have another finished project that is pretty damn original, as well. I'm trying to find a good way from stopping any guest from ever getting it before I release it. I will however release pictures so you can see what you ain't gonna get.
                  Last edited by MadGypsy; 05-13-2015, 12:39 AM.
                  http://www.nextgenquake.com

                  Comment


                  • #10
                    its great to see all this neat stuff being added to Quake. Some of this stuff would be very handy to have even when creating Quake 3 maps. Like the surface light thing. I know in Quake 3, you can write a shader to make textures give off light, but being able to make your own quickly, within radiant, would be so much more convenient.

                    I still think its amazing to see Quake still being kept alive so vigorously. Quake 3 doesn't get this treatment lol.

                    Comment


                    • #11
                      Originally posted by MadGypsy View Post
                      Another thing to consider is, a brush has 6 sides but, you are only going to be walking on one of them. This means there are 5 (potentially unseen) sides of that brush which will have lights attached to them. It does not take long, at all, before this dramatically increases your compile times. All for something that you are never even going to see.
                      This is not true.
                      The lighting routines are run AFTER the qbsp has been run. The qbsp will have removed any surfaces hidden inside walls. This means that ONLY the surfaces you see in the actual game will have any surface lights. There are no lights hidden inside walls.


                      regarding -subdivide 480, make sure that your light util is not erroring out due to surfaces exceeding the maximum supported size (vanilla limit).
                      I have not looked in to how surface lights are determined, but them depending on the -subdivide value makes them seem buggy.
                      Some Game Thing

                      Comment


                      • #12
                        @Spike, I do not doubt what you say at all, but I noticed with extra textures came extra compile times. I assumed this was due to light being applied everywhere. What else could be causing this?

                        I would like to say that 99% of these experiments end in an assumption based on observation. So, there is no doubt I could be wrong about some things.
                        http://www.nextgenquake.com

                        Comment

                        Working...
                        X