[baby_i_like_it]

Look Costin83 hey could make a skin like the Gignas Is That What I look for many websites that skin and never succeed if you could help me I would greatly appreciate it

[baby_i_like_it]

All these skins are great

[Costin83]

Originally Posted by Tirant Ahh, ok, that's right. I never thought of that, but I always knew about it. I didn't know it tied into that though. Basically, everything renders worse at a distance, even in CS, but not the models in CS. That's how sourcemod games can have such detail. Like if you want to see it noticeably, go in CS de_dust2, CT, go to long at, look at the ground and then walk. You can clearly see lines if rendering with obvious quality differences. Games like source and MW2 are a lot more adept at this. Like in MW2, it only renders directly in front of you, so if you turn around fast, you can catch the LOD changing. Hmm, thanks. I had two theory's on how they worked, but I think using a clients machine is better still, for the client with the shitty computers sake. lol Edit: I love this stuff... (after I actually read the page) "For example, a dodecahedron looks like a sphere from a sufficiently large distance and thus can be used to model it so long as it is viewed from that or a greater distance. However, if it must ever be viewed more closely, it will look like a dodecahedron. One solution to this is simply to define it with the most detail that will ever be necessary. However, then it might have far more detail than is needed to represent it at large distances, and in a complex environment with many such objects, there would be too many polygons (or other geometric primitives) for the visible surface algorithms to efficiently handle." God, friggen people are brilliant. This is how CoD works: (image from the site) This is sorta inspiring me to test this out in CS. Make a system where it renders different models at different distances. Same models, just discrete LODs. The only thing I would like to know is how the games handle zooming. Do they just render forward the zoom dist? I know in CoD when your zoomed everything in your peripherals is blurred, so maybe in MW2 and modern games, iron sighting narrows the FOV further to make it a little pinprick. Games like 1.6 have the sniper scope, so probably that renders ahead of the user, and I think the same for the AUG scopes. 1.6 is old, but you can learn a lot from it. I mean, what has any game besides Halo done that's different from it.

Those are called mipmaps if I recall well... It's just the textures getting smaller in the distance... it works quite alot like LOD models; same principle...

http://en.wikipedia.org/wiki/Mipmap

GoldSrc doesn't use lod's mipmaps, etc...
I think CSO (I'm not sure though... ) implemented some kind of lod model technology... Again, not quite sure... I just remember one day I've looked into some .nar's (archives like gcf's in steam) from CSO and bumped into some very lo-poly CS-Leet like model... and I thought that is used as lod model in CSO... who knows... never got into detail with that.


I always thought about requesting a plugin that will emulate lod models technology for CS 1.6 while playing on he maps.... But, then again I thought thaat it'll be quite a hassle to do the models and convincing some scripter to do the code... Now that you seem to be on the same side of the road, I must say that I'm more opened to this idea then before; Also I assume that you are a scripter besides the modeling stuff... Am I right ?
One more problem with lod's in CS 1.6 is the fact that many people use custom skins in their game, thus this is not a really important aspect because anyways lod's are meant to be low-poly and far in the distance...

I'm not sure, but if I may guess I think that zooming in games it's achieved by narrowing the FOV... and in modern games the lod's and mipmaps, etc. are recalculated...

Originally Posted by baby_i_like_it Look Costin83 hey could make a skin like the Gignas Is That What I look for many websites that skin and never succeed if you could help me I would greatly appreciate it

I didn't do the models myself; I've just ported them... Those are the default CS:S CT models.
Where did you found that picture anyways... ?

[Tirant]

I read the entire thing, so I know what mip maps are as well. I'm absolutely sure CS uses LOD technologies in maps. It's the blur at a distance. I can code enough to make what I want or need. When I get more of my MW2 mod done, I'll definitely try this out. It won't be as efficient, but I want to see the results.

[Costin83]

Originally Posted by Tirant I read the entire thing, so I know what mip maps are as well. I'm absolutely sure CS uses LOD technologies in maps. It's the blur at a distance. I can code enough to make what I want or need. When I get more of my MW2 mod done, I'll definitely try this out. It won't be as efficient, but I want to see the results.

I don't think CS 1.6 or HL1 use lod technology of any kind... From what I know maps in GoldSrc engine are "optimized" by other means to reduce the poly-count rendering.

[Tirant]

It depends on the map maker. I don't have the source code for the game atm, but I'm fairly sure that's how it works.

Look at this random picture I found on google. Look to the left of the crosshairs at the wall. Near the middle of the two towers, you can see an area where it is really clear/defined, then it goes out of focus. I'm 100% sure games like CS don't go out of focus or use overlays, and 3d things don't lose focus/detail, specially that close on their own. Look at a map ingame, then look at that same spot in a map viewer. I mean, it's obvious if you go to a long stretch of floor, look down and walk, you can see the lines where the render quality changes. It's not quite LOD, but I have no doubt it is probably something they intended as a possibly early implementation.


This picture is a bit more obvious then I think it normally is, but also a good example. Look at the ramp going down, or look at the wall directly in front of the player. You can see a clear detail change from good to horrid in a perfect line. From that line draw line a sphere around the player at that radius and you can see the detail shift everywhere.
[IMG]http://img25.**************/img25/1551/d2dlugabsa.jpg[/IMG]

[Costin83]

Those effects that you point there are all part of texture filtering effects...
There is no geometry changing of any kind. Just think at the fact that the walls are simply planes... walls don't have complex geometry... so you can't reduce their geometry complexity.
If you want to see geometry changing just look at more complex shapes... take for example the stairs; Take a look at the stairs while moving further and further from them... you will see that there will get blurry in the distance, but there won't change their shape... so that is no lod effect of any kind in GoldSrc...

http://en.wikipedia.org/wiki/Texture_filtering

The only geometry related stuff in CS 1.6 mapping it's cleverly making sky boxes that will hide as much poly's as possible and making walls that divides maps in more small rooms so the player won't see the entire map at once...

[Tirant]

I know there is no geometry changes, that would be absurd. I was pointing out that it does "texture filtering." Very interesting as well BTW, I always wondered what filtering was, I experimented last week in CS using the gl_ commands, so I knew it was textures, I just never assumed it was part of this effect I saw. There I go makin an ass of myself, lol. It's impossible to change geometry in and game in any map. Mappers have to be smart and use null and skyboxes properly. Like I said though, even though it isn't changing the geometry, changing the scale or quality of textures helps a lot when dealing with maps. So, in essence, it accomplishes the same thing. This feature is in the engine, not the map.

"incorrect filtering will show up in the image as artifacts (errors in the image), such as 'blockiness', jaggies, or shimmering." I've seen this in source mod games, finally understand "why?"

So, yes, I know it wasn't LOD, I didn't know it was called "texture filtering," but I had seen and played with it before (so I shoulda have known), and texture filtering accomplishes the same basic role of LOD (but for textures) as LODs do for modeling. It's impossible to change geometries for maps, cause first off, a map is one big model, so you can change all or none, and any change might be obvious due to the scale. Maps problem aren't complex geometry ever, its the textures on them associated with filtering (because soo many have to be filtered). I have yet to really see a map that renders more then 1,000-1,500 polys at once which is a pathetically small model to say the least.

It acts just like LOD does, just not by changing geometry. LOD = geometry, filtering = textures.
"As the textured surface moves farther away, the texture being applied switches to the prefiltered smaller size. Different sizes of the mipmap are referred to as 'levels', with Level 0 being the largest size (used closest to the viewer), and increasing levels used at increasing distances."

What I'm using then must be trilinear, cause I see gradual shifting. What the buy where it is obvious must be using bilinear.

If you want to witness this yourself, open hammer editor and make a map with 1 room and just a long plane. Compile the map. Next change all textures to 4x normal and compile. Next I want you to make one wall .25x and the other one 4x with the rest at 1x and experiment by looking at them both in turn. You'll see a difference. Make sure it is a big wall.

Once again, it's awesome talking with you, I'm learning a lot as well as figuring out what stuff means that I have always been aware of . Do you know all of this off the top of your head or just spend hrs on wiki? Wiki is a great resource. This is probably the most engaging forum conversation I've ever had with some random person. I have no doubt other people are reading it to find out about this stuff and learn what we know.

What I would like to figure out is how model smoothing works. Like how can a model be smoothed and look like it has more polies when it hasn't changed geometrically? I just think that is really interesting.

Another interesting think you might like to know cause you said you were interested in modeling is how 1.6 animations work. CS 1.6 animations on players work in two parts, bottom and top. they named it gait sequences.

http://en.wikipedia.org/wiki/Gait

Anyways, basically, the first 6-8 animations in a file are just leg animations (even though the upper body moves sometimes). And the upper body animations are the rest until about anim 100, when the death and flinch animations start which are full animations. This is a problem and why CS:S skeletons and animations won't work, because they are mostly full body animations, or I know that the zombies are . what I always wanted to do was take the time and develop a 1.6, source skeleton to get source animations on 1.6. I think doing that would be pretty sick. I'm not exactly sure how the engine handles it, but from what I gather, it determines upper from lower body by hitboxes above the pelvis I think. Meaning spine1 starts upper body. That why custom hitboxes, making the bones all the hitbox might fix it, but I have no idea of the consequences. So, if I made a 1.6, source skeleton, I would definitely copy the bone order as well, because that does influence it, and you an usually steal the hitboxes from the files .qc

[Costin83]

Originally Posted by Tirant I know there is no geometry changes, that would be absurd. I was pointing out that it does "texture filtering." Very interesting as well BTW, I always wondered what filtering was, I experimented last week in CS using the gl_ commands, so I knew it was textures, I just never assumed it was part of this effect I saw. There I go makin an ass of myself, lol. It's impossible to change geometry in and game in any map. Mappers have to be smart and use null and skyboxes properly. Like I said though, even though it isn't changing the geometry, changing the scale or quality of textures helps a lot when dealing with maps. So, in essence, it accomplishes the same thing. This feature is in the engine, not the map. "incorrect filtering will show up in the image as artifacts (errors in the image), such as 'blockiness', jaggies, or shimmering." I've seen this in source mod games, finally understand "why?" So, yes, I know it wasn't LOD, I didn't know it was called "texture filtering," but I had seen and played with it before (so I shoulda have known), and texture filtering accomplishes the same basic role of LOD (but for textures) as LODs do for modeling. It's impossible to change geometries for maps, cause first off, a map is one big model, so you can change all or none, and any change might be obvious due to the scale. Maps problem aren't complex geometry ever, its the textures on them associated with filtering (because soo many have to be filtered). I have yet to really see a map that renders more then 1,000-1,500 polys at once which is a pathetically small model to say the least. It acts just like LOD does, just not by changing geometry. LOD = geometry, filtering = textures. "As the textured surface moves farther away, the texture being applied switches to the prefiltered smaller size. Different sizes of the mipmap are referred to as 'levels', with Level 0 being the largest size (used closest to the viewer), and increasing levels used at increasing distances." What I'm using then must be trilinear, cause I see gradual shifting. What the buy where it is obvious must be using bilinear. If you want to witness this yourself, open hammer editor and make a map with 1 room and just a long plane. Compile the map. Next change all textures to 4x normal and compile. Next I want you to make one wall .25x and the other one 4x with the rest at 1x and experiment by looking at them both in turn. You'll see a difference. Make sure it is a big wall. Once again, it's awesome talking with you, I'm learning a lot as well as figuring out what stuff means that I have always been aware of . Do you know all of this off the top of your head or just spend hrs on wiki? Wiki is a great resource. This is probably the most engaging forum conversation I've ever had with some random person. I have no doubt other people are reading it to find out about this stuff and learn what we know. What I would like to figure out is how model smoothing works. Like how can a model be smoothed and look like it has more polies when it hasn't changed geometrically? I just think that is really interesting. Another interesting think you might like to know cause you said you were interested in modeling is how 1.6 animations work. CS 1.6 animations on players work in two parts, bottom and top. they named it gait sequences. http://en.wikipedia.org/wiki/Gait Anyways, basically, the first 6-8 animations in a file are just leg animations (even though the upper body moves sometimes). And the upper body animations are the rest until about anim 100, when the death and flinch animations start which are full animations. This is a problem and why CS:S skeletons and animations won't work, because they are mostly full body animations, or I know that the zombies are . what I always wanted to do was take the time and develop a 1.6, source skeleton to get source animations on 1.6. I think doing that would be pretty sick. I'm not exactly sure how the engine handles it, but from what I gather, it determines upper from lower body by hitboxes above the pelvis I think. Meaning spine1 starts upper body. That why custom hitboxes, making the bones all the hitbox might fix it, but I have no idea of the consequences. So, if I made a 1.6, source skeleton, I would definitely copy the bone order as well, because that does influence it, and you an usually steal the hitboxes from the files .qc

Take a look at these pictures:
You will notice how in HLMV the ground level or the absolute zero coordinates are at the same position as the skeleton's root bone (Bip01)
There's where the engine considers player origin


Even if the game's biped skeletons looks alot like the human skeleton let's not confuse the way they "work"
Human skeleton doesn't act like a tree like structure... not in the both ways anyway... While in real life the feet can be considered as a person's origin, in game the bone Bip01 witch it's almost at the same location as the pelvis gives us player's origin...
While you try to animate a walk sequence, you need to move the legs to imitate walking, and move the whole skeleton (meaning selecting Bip01 and moving it - Along with it, the whole skeleton will move) forth in the direction it's heading... Otherwise we will end up with a player that walk in place.

[Tirant]

Origin is just the center of an object. Always has been. The center of your model is centered like they should be which is at exactly 36 units. Your players entity (BBOX of your player) is above ground made not to go into objects. Its like dropping a box on a floor. The origin to the box is it's exact center, however, collisions are made with the sides of the box which prevent it from falling. through the floor to the origin. Basically, this part of the box is a players feet. That's why ingame if you look at players origins they are always 36 units above the floor. The reason I say 36 units is because players are 72 high, 32 wide x 32 deep. Crouched is 36 units (half), which is also the center of the players model. All a character is a box with a model that moves displaying animations. Thats why you change models but not the hitboxes or actual sizes of players.

I'm on my cell, so it's a lil hard to explain, but player models are no different then any models. They are just a visual non-solid reputation of a solid entity in-game.