Menu

Show posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Show posts Menu

Messages - K@rt

#16
WWMT Questions / Re: Actual Normals Issue
January 05, 2016, 12:11:32 AM
Yeah, that's how they should be looking!

A Normal is basically a statement of how light hitting the surface will be be bounced off, and this determines how we actually see the surface - because when you "see" any object you are seeing light that has already hit it and is returning to your eye. Normal maps give the impression of increased surface detail by changing the angle that light hitting the surface on a pixel by pixel basis, BUT the normal data is a "child" of the vertex normal data, i.e. the normalmap normals will be added to the vertex normals.

On your model the normals on the back of the jacket were almost lying flat on the surface, maybe some were even going back through it, which meant the light was being reflected almost vertically up or down along (or through) the surface of the jacket itself.

This means when looking at it directly on those areas would appear much darker than they should... the majority of the light is NOT being reflected back towards the observer. You would probably find as you moved around you model in the viewer there would be certain weird angles where those dark areas would suddenly become lighter. Like I said, generally you want your normals to be sticking out perpendicular to the surface as close to 90 degress as possible... this can be a problem on right angle corners which is why lighting can be a problem around edges, is why you will often choose to chamfer edges, and is in those kind of situations where edit normals is useful, and is the reason Shawn came up with the ww normal tools as well.

Here is a really nice little tutorial/explanation about normals on polycount:

http://polycount.com/discussion/154664/a-short-explanation-about-custom-vertex-normals-tutorial
#17
Clarification on rules... are displacements allowed or not?
#18
WWMT Questions / Re: Deform Model Problem
January 04, 2016, 10:05:20 PM
Here you go, I re-saved the scene with 2013 compatibility.

https://www.dropbox.com/s/5aw7rlrqphrbwv5/box_anim_example2013.rar?dl=0

As you have seen there are different animation techniques available in Source. Shawn obviously posted the video about wrinkle maps and also mentioned flexing/morphing, however all these are fairly specific techniques, usually concerned it smaller more subtle mesh manipulation that is too fiddly to be controlled with bones. I am not 100% sure but I think that the flex morphing that Shawns wrinklemap video shows can only be applied to models that are already rigged with a skin modifier.

For the majority of your day to day animation needs you will still be working with bones/skeletons and skin modifiers, so imo you need to get to grips with that first.

As Shawn says, each object will be considered a node... using $staticprop will effectively crush all the bones down into one single bone (which is usually the origin of the base node or object). When making models it is worth remembering this - different objects will each have their own bone whereas elements of one object will not... if you are making a character model with a skeleton it is worth bearing this in mind.

#19
WWMT Questions / Re: Deform Model Problem
January 04, 2016, 07:18:48 AM
Hey. Here is a link to a quick example file I made showing what I was explaining. Basically using six bones, four to squash the four sides in and out, one to control the height and one as a static base. The animation itself is very crude but it was just to give you an idea. I moved the bones directly and keyframed them manually, however you can also use controllers to move the bones if you prefer.

https://www.dropbox.com/s/kujxp5li0radwj5/box_anim_example.rar?dl=0

You then export to Source the model with the skin modifier and the bones. The weighting information for each vertex is compiled with the model and saved into the vvd file (I believe) and with most models the sequences are compiled directly into the .mdl file (except with characters or models using a LOT of animations)
#20
WWMT Questions / Re: Deform Model Problem
January 03, 2016, 11:27:15 PM
Basically in Source you need bones (or nodes) to make models animate. Each single vertex in your mesh will be weighted to a bone or bones... Weighting is basically information telling how much the vertex will be influenced by a particular bones movement, ranging from 0% (not effected at all) to 100% (completely effected). A single vertex can be weighted to multiple bones in percentages.

Lets say you have a vertex weighted to 3 different bones. It is weighted 50% to Bone01, 25% to Bone02 and 25% to Bone03. If Bone01 moves 10 units in the x-axis then the vertex will move 5 units in the x-axis... If Bone02 moves 4 units in the z-axis then the vertex will move 1 unit in the z-axis... and so on.

In your box example I think you would require 6 bones to make the animation work. You need one bone as a fixed base that doesn't move (this can often be the model node itself). Then you need 4 bones, one for each face that must push in and out (effecting the vertexes in the middle of the faces more than those at the top and bottom) and finally you need a bone that will stretch up and down providing the height.
#21
WWMT Questions / Re: Actual Normals Issue
January 03, 2016, 11:09:06 PM
Its a little hard to tell from those pics but it does look like part of the back of the jacket the normals are lying down almost flat on the surface of the jacket. This is probably why those areas are rendering very black. Even the normals on the arm look oddly oriented towards the front of the model. Normals don't always want to be pointing directly out perpendicular to the surface, but as a general guide that is a good starting place.

Here is a polycount thread about resetting normals: http://polycount.com/discussion/133315/how-do-i-reset-surface-normals-in-3ds-max
#22
WWMT Questions / Re: Happy New Year And New Question...
December 28, 2015, 09:07:21 PM
Yep, I agree with Shawn. Had a quick look at the file/tga and it renders exactly how you would expect it to...

Completely white areas = no transparency
Completely black areas = fully transparent
50% grey areas = 50% transparent
and so on..

If you want to mask the image so just the head is seen, follow Shawns instructions... make  the background completely black and make the head+shoulders completely white, with a little feathering around the edges to soften them.
#23
If FBX exporter in 2015 is broken, good chance it is broken in 2016 too. I have also had the memory leak Shawn mentioned, would advise staying with 2015 is you can... and if you are trying different versions FBS export I would suggest going back and not forward, try 2014 or 13 maybe.
#24
With these types of models it can sometimes be worth separating the translucent glass into a completely separate model, or at least separating out the translucent parts to a separate .vmt.
#25
Happy Birthday!!

They grow up so fast don't they ^^
#26
As Shawn says the "unaided" by scripts or plugins solution to the problem is to apply a PolySelect modifier to your object, select the face you want to edit, then put on a UWVMap with a planer map. You can do this for each individual face in your object, but it is a little time consuming. You can set up one box like that then clone it and edit it, but you will still need to adjust the parameters for each UVWMap, takes quite a lot of planning and thought.

Corvex now essentially gives you more or less the same control over texturing that the face edit tool does in hammer, each face can be manipulated independently and assigned different materials. It is a little different in its approach which you need to get used to a little bit when planning things, but I think that the majority of the texturing can be handled directly with its default controls, with maybe the odd occasion when post-corvex, specific UWMapping may need to be applied.

I don't know about how much you have used hammer, but as I got more experienced I didn't the vast majority of my brush manipulation in hammer using vertex mode. It is by far the best tool for making changes to large numbers of brushes, changing heights of buildings etc. (provided you know what you are doing). Working with corvex is (ironically) very similar to that I find, except that corvex is probably simpler and it is considerably less likely you will mess up :)
#27
Jori seems to know more about this suject than I do certainlly. When reading your post my first thought was of the progressively breakable door models you see in L4D2 and CSGO. Each time the door breaks the model falls back to a more damaged version of itself and spawns one or multiple gibs. If you could adapt the system to apply to characters, the main charcater model could fall back to character-model-minus-head which would still be fully dynamic model capable of playing one of a number of death animations, and the head could simply be spawned as a prop_physics gib to roll off and interact with the world however it wants to. As Jori said, these fall back models can have completely different skins to the original model, which eliminates any problem there. However achieving this may require the creation of new prop_data parameters as I don't know if the existing ones would allow for this setup.

In qucik answer to your question, I have no doubt that what you want to do CAN be done in Source, however whether current official versions of the engine/game are setup to make it practical, I am not sure.
#28
Quote from: CaptainCrazy on October 22, 2013, 02:09:01 PM
Okay tried it with a CSS skeleton and the same problem persists and my friend said my .QC is waaaaaay too small.  I guess i'll just have to give up hope that WW can do this and go back to the annoying old ways lol.

The skeleton isn't in the .qc file, it is in the base meshes .smd file. The .qc file only contains info about jointconstraints and bone merging and even with a full working skeleton will only be 5-10Kb....  i don't know in your friends world what "waaaaaay too small" corrosponds to, but in real terms gonna be about 7-8Kb at most**

But you don't need to try and tell from the size fo the .qc file... just open it in notepad - if you get jointconstrain and bonemerge and sequence info in it then it means the skeleton IS getting decompiled but you're not importing the .smd correctly into max. If the decompiled .qc file doesnt contain that info (and as I said before, if the main mesh .smd file doesnt start with a node list) then it means you are decompiling the models incorrectly in the first place.

Normally CS:S models are EASY to decompile and even the old, unedited versions of MDLdecompiler can handle them. With some later models (IDST1 format) MDLdecompiler won't work. Look for Crowbar, but I don't know if it has gone on general release yet or not.

The dropbox link I gave you above (to a decompiled custom CS:S model) contains a skeleton which imports fine into max. Now this is from somebodys custom model so it is still probably better to goto the Source original models... however the point is it works - try importing this and if you can't then its you who is making mistakes because I imported it fine.

Like I said before if you use the WW importers then you may lose the skeleton when it is imported, but its there in the smds so just use wunderboys importer instead.



**Oh, and as a foot note, in the meshes SMD file the skeleton itself will take up about 6kb of the total file (which will probabaly be between 1500-3000Kb in total) and the weighting info will probably be upto 500Kb in size, depending on the complexity... so it is pretty much impossible to look at the size of an SMD file and KNOWwhether the skeleton is there either.
#29
Im afraid I have no idea what your level of knowledge is about all this. To export the bones with the model you must use a skin modifier. With your character model object selected you drop down the modifier stack until you find "skin" then add it.

After that you must add the bones into the modifer using the "ADD" function in the modifier properties. You add ALL the bones here.

Finally you must set all the weights correctly in your skin modifier (which is a pain and takes ages)... you basically need to tell each vertex which bone moves it, some vertexs will be moved by multiple bones. Here is a simple explaination of weighting on an arm:

http://www.youtube.com/watch?v=y9-y1bJjoWo

When you export/compile you model the bones and weights will be in the main mesh smd file... you can tell if the bones are there correctly as the smd will start with a list of "nodes" one for each bone. With smdexporter (wunderboys) you simply select everything and export to smd, WWMT should recognise the skin modifier and export all the bones and mesh into the smd.
#30
Think it depends whether you game has been Steam piped. If it HASN'T been piped then they will be in:

Drive:\Program Files (x86)\Steam\steamapps\counter-strike source shared.gcf

and if it has been piped it should be in

Drive:\Program Files (x86)\Steam\steamapps\common\counter-strike source\cstrike\css_pak_dir.vpk

(not sure if its css_ or something else, but close to that)


Here is the smd for a custom Counter-Terrorist model I just grabbed from Gamebanana and decompiled:

https://www.dropbox.com/s/ifnc8q2l6ed23j9/ct_gign_soldier.smd

and here is the ragdoll sequence that is compiled directly into the model:

https://www.dropbox.com/s/6srn82mj5ndoxh3/ragdoll.smd

(not necessary to import ragdoll into max, just add it back into the .qc when you recompile your model using

$sequence ragdoll "ragdoll" ACT_DIERAGDOLL 1 fps 30.00
SMF spam blocked by CleanTalk