SC2Mapster

@xXdRaGoNrIdDeRXx: Go

So it's working right? :) Could you attach the .max file even if it's ok?

@harvy2008: Go

The test is required in order for the model to be compatible. The arbiter model was working because it was using pixel-to-pixel method. This method is not very effective. The previous version did not support it, so the models had serious compatibility issues. If you look closely, all the models in the game have the tight test structure. Some of them are using it, some of them are not. But the structure is always there.

Here are some examples and models:

You can enable /disable display of the test inside the editor:

The antenna does not have the tight test, the same with the tree. Therefore, there is no bone to support the test objects.

If you look at units such as Marine or Battlecruiser, you can see that they have both tight and fuzzy tests.
And there are the bones to which the test are attached.

If you import the Battlecruiser model the tests will be there there. The thing is that they are hidden. So I don't need to attach the working max file, you just have to import the model and there you are - working model.

All the imported objects are distributed into layers:

You do not need to separately include the test during every export. You just need place the test object once, add it to a bone and it will stay there.

I hope this helps you understand why and when to add the tight body.

EDIT: oh, and you only need to test the objects if you're creating clickable objects. Any other object can be exported without the test (exporter will automatically add null test structure but it will still be compatible).

Tree and antenna are not selectable - that's why you don't have bones and tests attached. Marine and Battlecruiser are selectable - that's why they have the tests and bones which support the tests.

@Kailniris2: Go

Ok :) Nincs harag. Remélem, hogy a fordítás jó. A vizsgálati szükségesek összeegyeztethetőségének modell. A döntőbíró működött, mert használt pixel-to-pixel módszerrel. Ez a módszer nem túl hatékony. Az előző verziójához azt nem támogatta, így a modellek voltak komoly kompatibilitási problémák.
Ha jobban megnézed, minden modell a játékban van a "szűk" szerkezet. Néhány ezek közül használja, némelyik nem. A szerkezet mindig ott van.

Íme néhány modell és példa:






Tudod engedélyezése / tiltása a vizsgálat kijelzőn:

Az Antena modell nem rendelkezik a vizsgálatok, ugyanaz a fa. Ezért nincs csontokat, hogy támogassa a teszt objektumok.

Ha megnézzük egységek, mint Battlecruiser vagy Marine vannak tesztek, mind a feszes és fuzzy.
És ezek a csontokat, hogy mely a vizsgálatok kapcsolódnak.

Ha importálja a Battlecruiser modellt max, akkor a teszt ott. Az egyetlen dolog, hogy azok rejtettek. Nem kell csatolni olyan dolgozó max fájl, akkor létre magadnak az importáló a kívánt modellt.

Az objektumok által importált max kerülnek újraelosztásra rá rétegeket.


Nem kell, hogy tartalmazza a vizsgálatok minden export. Csak azt kell helyezni a vizsgálat után, adjunk hozzá egy csont, és ez marad ott.


Remélem, ez segít megértésében, hogy miért és mikor kell hozzáadni a tight test.


EDIT: oh, és csak akkor kell vizsgálatot a kívánt objektumokat Ez kattintson rá. Bármely más objektum nem kell a vizsgálat.

Fa-és az antenna nem választható tárgyak nem rendelkeznek vizsgálatokat. Marine és a Battlecruiser a választható tárgyak és ezért vannak tesztek.

I like how grunt's portrait are his legs :) (I know, it's alpha)

Which of the models here are created by you/your team?

@Kailniris2: Go

What max are you using? If other than 2011 then, with all due respect, switching to 2011 would save you a lot more time. Additionally, I suspect that everyone who cares in the slightest about Blizzard's tools already submitted to the beta which will be max2011.

The "guide" (as you've put it) explains exactly why you need this method which wasn't present in previous version.

I don't like the attitude you've shown in the last post. I'm doing my best to make it work. So next time show a bit of respect if not for me then at least my free time.

@HatsuneMikuMegurine: Go

Quote from Leruster: Go

Tight and Fuzzy hit tests: Now these tests are really important to the compatibility of the custom model with the game itself. Every model that is clickable in the game has those two tests (of course it is not mandatory to the bushes or trees objects, only the clickable ones). So it's rather important that you include those two in the next export that you do :) What is the difference? If you open up the editor, there any unit model (let's take again - the corruptor) and click RENDER -> SHOW GEOMETRY -> HIT TESTS you can see that there are a few capsules. The blue one is the tight test and it is used when the game tries to figure out whether you are including the unit with the box selection method or not. The green one is the fuzzy test and it is used when you click the unit to select it. There can be only one tight test in the scene, but you can have as many fuzzy tests as you want. Tight test should encapsulate the entire model within it, fuzzy test should build less overall shape of the model. I strongly recommend checking out original models to figure out what method of placing those is the right one.

Skin and bone attach changes: If you click on ribbon, pemitter, tight or fuzzy test you'll notice that there is this common button with label "Parent:" In this version, if you won't attach the sc2helpers to the bones or if you won't skin the geometry, the script will not do it during the export phase. I did this to increase the compatibility and to have this "user-side-check" whether everything is ok or not.

If you use the PICK BUTTON provided with the helpers, you will see that it will bring down the helper to the bone's position. That's because the helper's transformation is irrelevant. The only thing that matters is bone's transformation. Except if you are picking a bone for tight or fuzzy test. These tests can have their own set of transformations which are added to the bone's transformations. Resulting transformation is the one that will be taken under consideration in game.

For all the 2012 users: I've checked it, you need to always include the tight test in your models. Need to fix it :/

Doesn't the imported w3 model have all the animations for build and work and stand? Can't you just separate it into builidng_build.m3 and building.m3?

Ok so try this:
Instead of producing normal map in max, render to texture a height map.
Then open that map in photoshop and:
a) copy the image to two seperate layers
b) on the first one apply embos filter with direction 0deg and 2px
c) on the second layer apply the same embos but with direction 90deg
d) take the first modified layer to green channel
e) take the second modified layer to alpha channel
f) fill red with white and blue with black.
g) save as .dds and check how it behaves in the editor.

Why embos? Well if you look at say Zealot normal map or any protoss or terran normal map you can see that they don't look generated but rather drawn. If you draw a white line on a grey (149,149,149) background and apply the embos it will generate something that looks EXACTLY like one of the channels of any original StarCraft II normal map. The directions are obvious and the mapping layout as well as the orientation of faces of the mapping seem to be irrelevant.

If you think about it, you can generate so much information just from the data provided by the two channels (green and alpha). You can combine those two and tell how high the element should be, what's the height of a bump. And actually that should be enough to recalculate it to give the proper normal.

EDIT:
Of course, that kind of height map requires some editing to add it a bit of contrast so that the high elements are white actually. Proper level editing does the trick.

You should set you poly limit according to the size of the unit. Say drone has less polys than Queen has. This ratio poly/volume.

I recommend importing a few models and checking out what's going on there.

I once accidentally imported one model which was like 150k polys and it also was displayed properly ;)

I wish I could dislike it twice or even three times. The world is full of creative minds who create so much different music.
But it had to be this one right? "The introduction"? -_-

First of, you need to move your mapping a bit out of sides. Generally it is a good practice to leave a bit of space between the mapping and the mapping boarders.

Now instead of flipping the mapping itself, maybe you should try to flip green of the normal map?

When you bake normal maps you need to ensure that both objects have reset scale (ie. in max 100, 100, 100).

That's at least what I do (besides the flipping green) and it works for me just fine :)

@Zolden: Go

No because just because there is no map it doesn't mean that the layer is not doing anything. Good example is the gateway's black sphere. Emission (as far as I remember) has a color but it doesn't have any map.

Actually, you're right. I thought this through and we could find a compromise here. The point of that was to ensure the full compatibility, not to loose any information on there.
But I guess when you don't have layers without maps it's easier to figure out what does what.

I will add an import option to either import every layer (Compatibility mode) or just the ones that have maps (Figuring out mode :) ). Thanks for that suggestion.

I will post a new version today, maybe tomorrow and let you know.

@Zolden: Go

Ok so let's do it this way:
I release test version with projection support and you figure out what parameter is responsible for what. Deal?

@Kailniris2: Go

Probably :) I honestly want to wait for the Blizzard's tools. Figuring out all the structures and what does what just takes soooo much time :/

@Kailniris2: Go

Told you, lightnings are using sRib structure which is not supported. It basically anchors the ribbon to a specific bone.