Okay Merkaba...
BigD
[OldF] Join Date: 2002-10-25 Member: 1596Members
[OldF] Join Date: 2002-10-25 Member: 1596Members
<div class="IPBDescription">how'd you make NS so sexy.</div>Machina was and still is amazing... but one touch in the final version... one more thing you did, the first thing you see when you load the map and find yourself in the new readyroom. (The room itself, is simple and seems to just be a shrine, or a theater... looking out upon a new stage.)
Did you poke Charlie and his code monkeys to put some spirit of HL code in? Heck, I don't even know if SoHL can do it as nicely as you have.
I know you briefly mentioned how you'd implement such a thing before using models and such, (can't remember where though) and I thought it was mere theory and didn't understand how it'd work in the end. I gotta say though, the final result is an amazing upgrade to one of the HL engines "uglies". Sure, even old engines like the Unreal engine have done it for a coons age, and it's pretty trivial to accomplish in Source, but to see it in this "old" game... I love it!
So, for the benefit of all future NS maps, how'd you make them 3D skyboxes? <img src="style_emoticons/<#EMO_DIR#>/smile-fix.gif" style="vertical-align:middle" emoid=":)" border="0" alt="smile-fix.gif" />
Did you poke Charlie and his code monkeys to put some spirit of HL code in? Heck, I don't even know if SoHL can do it as nicely as you have.
I know you briefly mentioned how you'd implement such a thing before using models and such, (can't remember where though) and I thought it was mere theory and didn't understand how it'd work in the end. I gotta say though, the final result is an amazing upgrade to one of the HL engines "uglies". Sure, even old engines like the Unreal engine have done it for a coons age, and it's pretty trivial to accomplish in Source, but to see it in this "old" game... I love it!
So, for the benefit of all future NS maps, how'd you make them 3D skyboxes? <img src="style_emoticons/<#EMO_DIR#>/smile-fix.gif" style="vertical-align:middle" emoid=":)" border="0" alt="smile-fix.gif" />
Comments
Thats what I make of it <img src="style_emoticons/<#EMO_DIR#>/tounge.gif" style="vertical-align:middle" emoid=":p" border="0" alt="tounge.gif" />
A friend of me did it too in a CS map, for buildings, and, it's very amazing <img src="style_emoticons/<#EMO_DIR#>/smile-fix.gif" style="vertical-align:middle" emoid=":)" border="0" alt="smile-fix.gif" />
Basically, how I did the machina readyroom (and the rest):
1) Edit your map properties and set the max viewable distance to however far away your object will be. In machina this is something like 4,000,000 units, but the larger the number the more likely it seems that ATI card users will experience some Z-buffering in the skybox.
2) Learn to model.
3) Once you've done that, understand how models work in Half-Life (and every other game out there AFAIK):
The origin of the model, the position 0,0,0 in MAX,milkshape or whatever program you use, is where the model gets placed in the world. So, if you had a model of a human and his belly button was at position 0,0,0 in the model file, and then placed a model entity into your map that is on the floor, then in-game his legs would be buried in the ground and you would only see him from his belly button upward as his belly button is where the entity's position is.
Now, the model data doesn't actually have to be anywhere near the origin. So, realising this I did some experiments and made a sphere that was 100,000 units across and 500,000 units away from the origin, and then put that into the map - lo and behold, I had crystal sharp a moon floating in the distance, even though my entity was inside the map.
And that's really all there is to it. The ship and asteroids and moon are all one very, very, very big model. The stars and the sun are a seperate model that is additively rendered, to be certain that they are glowing brightly.
So it is perfectly viable to have animated skyboxes using this method, if you wish.
However there are limitations:
- Additively rendered models will cause problems behind a texture-rendered wall (eg a window). All the windows in machina are additively rendered because of this.
- Since the model is being drawn from a point entity (env_sprite is what machina uses), as soon as that entity leaves the POV (potential visiblity set - gl_wireframe 2) the model will disappear. So, if you have a large window and want a scene visible through it, then the entity which holds the model MUST be visible at ALL times whilst that window is in view. By visible I mean in the POV set, and it does not have to be in front of the player.
- If you desire to have different angles of the same scene visible from seperate windows, that is, windows in isolated POV sets, you must have a different model for each window. As an example, the model you see out of the window in Arrival & Departure in Machina is NOT the same model as you see out of the Marine Start, even though they both have the TSA ship visible. The reason for this is that if I had the marine start model in arrival & departure, then it would not be re-positioned relative to where the player has moved, and so the TSA ship would still be just as far away.
There are 4 'isolated POV sets' with models in them in machina, The Readyroom, the Marine Start, Arrival & Departure, and Tau Ceti.
- Models are lit based on the brightness of the ground beneath the holding entity. So, if you want your model to appear fullbright, it must be on a patch of ground that is very bright white. If you can get away with it, making your model additively rendered fixes this but also makes the model transparent.
- If a model is near SKY, then it will most likely take on the light properties that the sky gives off. This was a huge pain in machina and is what prompted me to end up having the stars & sun additively rendered. The rocks in Tau Ceti are actually affected by this - they are more orange than the rest of the rocks in the game (due to the orange lighting). All the other skybox details in Tau Ceti are additively rendered and so are not affected.
This is also why many of the 'sky' windows in machina are actually textured with NULL, to stop my models from being orange. The sky in the RR is NULL and the light is faked by having a light hidden behind some NULL brushes at a position such that much of the light is blocked by the NULL brush but much of it also falls into the RR, faking the light being blocked by the asteroid.
And I think that's all the problems I encountered...I am not certain of this but I don't think models can be rotated either. However, I never really tried with much heart so I could be wrong there <img src="style_emoticons/<#EMO_DIR#>/smile-fix.gif" style="vertical-align:middle" emoid=":)" border="0" alt="smile-fix.gif" />
Any other questions about this please ask!
The ATI issues you speak of, is this why I see little "triangles" now and then, particularly in the Tau Ceti sky? I have no issue with it, sort of makes the stars look like they are twinkling!
The thing I love with something like this, is the "floating building" feeling one gets when looking out the windows of veil, or such with the old style skybox could be alleviated (somewhat) with this. Looking outside of Ayumi for example, instead of a cliff "conveniently" blocking the horizon, one could make a vast plane, additively rendered into the darkness on the horizon.
Now I just need to work on step 2! <img src="style_emoticons/<#EMO_DIR#>/tounge.gif" style="vertical-align:middle" emoid=":p" border="0" alt="tounge.gif" />
Now I just need to work on step 2! <img src="style_emoticons/<#EMO_DIR#>/tounge.gif" style="vertical-align:middle" emoid=":p" border="0" alt="tounge.gif" />
<!--QuoteEnd--></div><!--QuoteEEnd-->
Learning to model/skin/skinmesh?
Maybe in the next NS version we can release updated versions of many maps with fancy skyboxes? <img src="style_emoticons/<#EMO_DIR#>/smile-fix.gif" style="vertical-align:middle" emoid=":)" border="0" alt="smile-fix.gif" /> Of course we'd need to get hold of the mappers for that...
I want to 'sexify' ns_hera and put in some more clorfs & distance stations. But the big question I suppose is...is it worth it? I suppose having a mass skybox overhaul of NS maps would be a good publicity stunt ("Look at what we've done to the Half-Life engine!").
It would be great to see proper skyboxes in many NS maps. I tried to get KFDM to explore having a seabed model for ns_altair, but I guess it was just forgotten :[
Maybe in the next NS version we can release updated versions of many maps with fancy skyboxes? <img src="style_emoticons/<#EMO_DIR#>/smile-fix.gif" style="vertical-align:middle" emoid=":)" border="0" alt="smile-fix.gif" /> Of course we'd need to get hold of the mappers for that...
I want to 'sexify' ns_hera and put in some more clorfs & distance stations. But the big question I suppose is...is it worth it? I suppose having a mass skybox overhaul of NS maps would be a good publicity stunt ("Look at what we've done to the Half-Life engine!").
<!--QuoteEnd--></div><!--QuoteEEnd-->
Yeah, I think you told me about your idea over a year ago. I forgot ^_^. Maybe for 3.3 ;p
That's right, it's all done using models. Valve could have done it with Half-Life if the GFX cards at the time could handle it.
Basically, how I did the machina readyroom (and the rest):
1) Edit your map properties and set the max viewable distance to however far away your object will be. In machina this is something like 4,000,000 units, but the larger the number the more likely it seems that ATI card users will experience some Z-buffering in the skybox.
2) Learn to model.
3) Once you've done that, understand how models work in Half-Life (and every other game out there AFAIK):
The origin of the model, the position 0,0,0 in MAX,milkshape or whatever program you use, is where the model gets placed in the world. So, if you had a model of a human and his belly button was at position 0,0,0 in the model file, and then placed a model entity into your map that is on the floor, then in-game his legs would be buried in the ground and you would only see him from his belly button upward as his belly button is where the entity's position is.
Now, the model data doesn't actually have to be anywhere near the origin. So, realising this I did some experiments and made a sphere that was 100,000 units across and 500,000 units away from the origin, and then put that into the map - lo and behold, I had crystal sharp a moon floating in the distance, even though my entity was inside the map.
And that's really all there is to it. The ship and asteroids and moon are all one very, very, very big model. The stars and the sun are a seperate model that is additively rendered, to be certain that they are glowing brightly.
So it is perfectly viable to have animated skyboxes using this method, if you wish.
However there are limitations:
- Additively rendered models will cause problems behind a texture-rendered wall (eg a window). All the windows in machina are additively rendered because of this.
- Since the model is being drawn from a point entity (env_sprite is what machina uses), as soon as that entity leaves the POV (potential visiblity set - gl_wireframe 2) the model will disappear. So, if you have a large window and want a scene visible through it, then the entity which holds the model MUST be visible at ALL times whilst that window is in view. By visible I mean in the POV set, and it does not have to be in front of the player.
- If you desire to have different angles of the same scene visible from seperate windows, that is, windows in isolated POV sets, you must have a different model for each window. As an example, the model you see out of the window in Arrival & Departure in Machina is NOT the same model as you see out of the Marine Start, even though they both have the TSA ship visible. The reason for this is that if I had the marine start model in arrival & departure, then it would not be re-positioned relative to where the player has moved, and so the TSA ship would still be just as far away.
There are 4 'isolated POV sets' with models in them in machina, The Readyroom, the Marine Start, Arrival & Departure, and Tau Ceti.
- Models are lit based on the brightness of the ground beneath the holding entity. So, if you want your model to appear fullbright, it must be on a patch of ground that is very bright white. If you can get away with it, making your model additively rendered fixes this but also makes the model transparent.
- If a model is near SKY, then it will most likely take on the light properties that the sky gives off. This was a huge pain in machina and is what prompted me to end up having the stars & sun additively rendered. The rocks in Tau Ceti are actually affected by this - they are more orange than the rest of the rocks in the game (due to the orange lighting). All the other skybox details in Tau Ceti are additively rendered and so are not affected.
This is also why many of the 'sky' windows in machina are actually textured with NULL, to stop my models from being orange. The sky in the RR is NULL and the light is faked by having a light hidden behind some NULL brushes at a position such that much of the light is blocked by the NULL brush but much of it also falls into the RR, faking the light being blocked by the asteroid.
And I think that's all the problems I encountered...I am not certain of this but I don't think models can be rotated either. However, I never really tried with much heart so I could be wrong there <img src="style_emoticons/<#EMO_DIR#>/smile-fix.gif" style="vertical-align:middle" emoid=":)" border="0" alt="smile-fix.gif" />
Any other questions about this please ask!
<!--QuoteEnd--></div><!--QuoteEEnd-->
*looks at text in aw*
Well.... I'm pretty sure my map wont have skybox thingy things... I got hard enough time making an elevator or a door (i dont know how to make them at all really!), let alone a whole sky. I still have yet to scratch the surface on step 2 (maybe I have, I'm not sure <img src="style_emoticons/<#EMO_DIR#>/confused-fix.gif" style="vertical-align:middle" emoid="???" border="0" alt="confused-fix.gif" /> ) because I really only know how to use these entities: light entities (kinda), info_maplocation and func_water.
(sort of back on track) I'm impressed with the skybox thing and the whole map itself. I wont be able to match up ever, so thats why I'm going to make maps that please the competitive community or the "Gameplay > Prettiness" people.
BTW. I'm probably one of the only people who doesn't like the map just because i get lost every 15 seconds and the minimap doesn't help me much (small brain i got <img src="style_emoticons/<#EMO_DIR#>/tounge.gif" style="vertical-align:middle" emoid=":p" border="0" alt="tounge.gif" />), but likes everything else about it.
But what i dont get is..
<!--quoteo(post=1612207:date=Mar 7 2007, 05:18 PM:name=Merkaba)--><div class='quotetop'>QUOTE(Merkaba @ Mar 7 2007, 05:18 PM) <a href="index.php?act=findpost&pid=1612207"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->Since the model is being drawn from a point entity (env_sprite is what machina uses)<!--QuoteEnd--></div><!--QuoteEEnd-->
env_sprite? I cant seem to get the entity to open any of the model files. Was this a typo, or am i missing something? I tried to manually link the sprite to the models, and Hammer crashed <img src="style_emoticons/<#EMO_DIR#>/tounge.gif" style="vertical-align:middle" emoid=":p" border="0" alt="tounge.gif" />.
A Cycler opens them just fine. Is this what you actually used?
<a href="http://collective.valve-erc.com/index.php?doc=1050662008-07225900&page=2" target="_blank">Making Models Appear</a>
<!--c1--><div class='codetop'>CODE</div><div class='codemain'><!--ec1-->To make a model appear in the 3D view, three things must be done. First, the "Game Directory" (and/or "Mod Directory") property in Tools / Options / Game Configurations must be set. Second, the models must be unpacked into the proper folder. Third, the entity definition in the FGD must include the studio() helper. This is done one of two ways.
case 1:
@PointClass studio() = entity_name
[
model(studio) : "Model"
]
In this case, the entity initially appears as the flatshaded box we've come to know and love, until a model is specified for its "model" property, at which time the model is then displayed in the 3D view.
case 2:
@PointClass studio("models/some_model.mdl") = entity_name []
In this case, the model is explicitly defined in the entity properties, and will always appear as this model in Hammer's 3D view.
Note that in either case, the model must be present in the specified folder or it will simply appear as the flatshaded box.<!--c2--></div><!--ec2-->
Technically, you can do this with any model/sprite entity. I forget what I ended up using for the chairs in moira, but some model entities provide a small useless hitbox, or other weirdness, so I played around with a couple different versions and ended up with something with no hitbox and made my own in the map using clip brushes. I "think" it was env_sprite that I used for that.
Anyway, hope it works well for you!
The nice thing about env_sprite over a cycler, if my memory serves me:
No hitbox
No weird "use animations" (not a problem with static props usually)
I dunno, your mileage might vary too. Try'em both. Unfortunately I haven't bothered to try to get hammer running under Wine yet so I can't open it up and tell you exactly what I did. But, I'm willing to bet that if Merkaba figured on env_sprite, he had something of a reason for doing so. Hard to tell.
<u><!--sizeo:3--><span style="font-size:12pt;line-height:100%"><!--/sizeo-->EDIT OF THE EXTREME SENSE:<!--sizec--></span><!--/sizec--></u>
Wait a second, I sort of cut'n pasted that above how-to without reading it. It really isn't too clear (intended for freshly made .fgd entries rather than editing existing ones.) I found a better description in yonder <a href="http://www.chatbear.com/unity2/9/405,1071869995,22205/583190?v=flatold" target="_blank">verc forums:</a>
<!--quoteo--><div class='quotetop'>QUOTE</div><div class='quotemain'><!--quotec--><!--coloro:#FFFF00--><span style="color:#FFFF00"><!--/coloro-->1. you have to use FORWARD slashes in the path: <!--colorc--></span><!--/colorc-->
<!--fonto:Courier New--><span style='font-family: "Courier New"'><!--/fonto-->models/player/gman/Gman.mdl <!--fontc--></span><!--/fontc-->
<!--coloro:#FFFF00--><span style="color:#FFFF00"><!--/coloro-->2. You need to edit env_sprite in the fgd. Open the fgd and search for env_sprite, it will look like something like this: <!--colorc--></span><!--/colorc-->
<!--fonto:Courier New--><span style='font-family: "Courier New"'><!--/fonto-->@PointClass <!--coloro:#FF0000--><span style="color:#FF0000"><!--/coloro--><u>sprite()</u><!--colorc--></span><!--/colorc--> base(Targetname, ...) = env_sprite : <!--coloro:#8B0000--><span style="color:#8B0000"><!--/coloro-->"Sprite Effect" <!--colorc--></span><!--/colorc-->
[
<blockquote><!--coloro:#696969--><span style="color:#696969"><!--/coloro-->framerate(string) : "Framerate" : "10.0"<!--colorc--></span><!--/colorc-->
model(<!--coloro:#ccccFF--><span style="color:#ccccFF"><!--/coloro-->sprite<!--colorc--></span><!--/colorc-->) : <!--coloro:#8B0000--><span style="color:#8B0000"><!--/coloro-->"Sprite Name" <!--colorc--></span><!--/colorc-->: "sprites/glow01.spr"
<!--coloro:#696969--><span style="color:#696969"><!--/coloro-->scale(string) : "Scale" : ""
spawnflags(flags) =
[
1: "Start on" : 0
2: "Play Once" : 0<!--colorc--></span><!--/colorc-->
]</blockquote>
]<!--fontc--></span><!--/fontc-->
<!--coloro:#FFFF00--><span style="color:#FFFF00"><!--/coloro-->Change the red parts above to look like the green parts below: <!--colorc--></span><!--/colorc-->
<!--fonto:Courier New--><span style='font-family: "Courier New"'><!--/fonto-->@PointClass <!--coloro:#00FF00--><span style="color:#00FF00"><!--/coloro--><u>studio()</u><!--colorc--></span><!--/colorc--> base(Targetname, ... ) = env_sprite : <!--coloro:#008B00--><span style="color:#008B00"><!--/coloro-->"Sprite/Model Effect"<!--colorc--></span><!--/colorc-->
[ ...
<blockquote>model(<!--coloro:#ccccff--><span style="color:#ccccff"><!--/coloro-->sprite<!--colorc--></span><!--/colorc-->) : <!--coloro:#008B00--><span style="color:#008B00"><!--/coloro-->"Sprite/Model Name"<!--colorc--></span><!--/colorc--> : "sprites/glow01.spr"</blockquote>
...
]<!--fontc--></span><!--/fontc-->
Notice the <!--coloro:#ccccff--><span style="color:#ccccff"><!--/coloro-->blue<!--colorc--></span><!--/colorc--> part. This is how Hammer determines what file extension to show when
you click the [...] button. model(sprite) will browse the sprites folder by default,
and if you change it to model(studio) it will browse the models folder by default,
so just put which ever you think you'll use most often. All other file types will be
hidden except for the one you specify in the fgd, but to get it to show all
files, put an asterisk * for the filename and press Enter. You of course can also just type the file in manually, remembering to use FORWARD slashes.
Also note that "sprites/glow01.spr is just the default sprite or model that is diplayed.
If you're using Hammer 3.5 beta, you can specify a model here if you like (e.g. models/barney.mdl)<!--QuoteEnd--></div><!--QuoteEEnd-->
I hope that's a bit more helpful. Swapping between models and sprites really is actually quite easy. Also remember that you need to reload Hammer when you change your .fgd!
Sidenote: The <!--coloro:#8B0000--><span style="color:#8B0000"><!--/coloro-->dark red<!--colorc--></span><!--/colorc--> fields don't <i>need</i> to be changed (in fact, I never thought to when I made the changes.) Just the "<!--coloro:#FF0000--><span style="color:#FF0000"><!--/coloro--><u>sprite()</u><!--colorc--></span><!--/colorc-->" has to be. But, it wouldn't hurt to change it, and it might make it easier to remember what you can do with the env_sprite in the future!
...and what does the cycler entity look like, compared to the modified sprite?
I took a look at them, and yeah, it looks like we'd simply be redefining the env_sprite into a cycler.
Some forums are saying that getting a newer FGD can fix Hammer crashing when loading a model into an env_sprite. But now I cant find any reference to if i have the newest FGD or not <img src="style_emoticons/<#EMO_DIR#>/sad-fix.gif" style="vertical-align:middle" emoid=":(" border="0" alt="sad-fix.gif" /> (apparently 'fgd' is too small of a word to be allowed in the Forum Search, fantastic)
...I'm also noticing that my FGD says its for NS 2.1. What the hell? Does it not get updated with the patching, or does everybody's FGD say that?!
Basically, the way I understand it, the env_sprite has been able to handle models for <i>years.</i> It (like many halflife entities) simply wasn't named appropriately since the start. All you're doing is making it so that <i>Hammer</i> expects a model instead of a sprite to be loaded in its viewer (which is great for prop models, so you can turn them and face them where you want them without having to load it in the game, realize it's upside down or whatever, redo it, etc.)
And yeah, studio() refers to models, not sure why it's called that but yeah. Those "newer" .fgd's are probably talking about custom .fgds where this change is done for you. (And most likely those posts are from the era when 3.5beta was first released!) I believe DoD is the only "official from valve" fgd that has been updated in such a way (thank the DoD guys for this feature!) The only thing is, the change wasn't finished in that it ought to be able to handle the switch on the fly (hence why 3.5 was only ever "beta").
Also, I'm pretty sure the cycler has a hitbox, a little cube centered around the models origin point that's useless for most purposes (particularly yours), and you can't edit that out unfortunately. I could be wrong though and thinking of another model entity.