Install Steam
login
|
language
简体中文 (Simplified Chinese)
繁體中文 (Traditional Chinese)
日本語 (Japanese)
한국어 (Korean)
ไทย (Thai)
Български (Bulgarian)
Čeština (Czech)
Dansk (Danish)
Deutsch (German)
Español - España (Spanish - Spain)
Español - Latinoamérica (Spanish - Latin America)
Ελληνικά (Greek)
Français (French)
Italiano (Italian)
Bahasa Indonesia (Indonesian)
Magyar (Hungarian)
Nederlands (Dutch)
Norsk (Norwegian)
Polski (Polish)
Português (Portuguese - Portugal)
Português - Brasil (Portuguese - Brazil)
Română (Romanian)
Русский (Russian)
Suomi (Finnish)
Svenska (Swedish)
Türkçe (Turkish)
Tiếng Việt (Vietnamese)
Українська (Ukrainian)
Report a translation problem
But, as I understand it, when you export to various game engines the scale can change. I'm not sure there's anything you can do except export a 1x1x1 cube, import it into the game engine and then work out the difference in scale then go back and apply that to your model in Blender before exporting it.
So if your model should be exactly 1m wide but is only 0.2m in the game engine then you will need to scale your model in Blender by 5 times before exporting it. You can perform calculations in the number input boxes in Blender. So if your model is something more complex like 1.234 and you need to scale it by 0.89 then you can just change the size box from "1.234" to "1.234 * .89" and when you hit return Blender will calculate the answer for you.
Hopefully someone who knows more about this than me can jump in and give you some better advice.
Thanks for the advice. I sorted some things out but still I can't find an exact equivalence. The thing with the Source Engine is that I have two scales.
My first scale is within Blender, the size (scale) of my object. The second one is in a file that must be written so I can compile another file that will contain my model but will be readable for the Source Engine. There is no way (as for now, from what I know) to avoid that second scale.
Explaining my last attempt (05:45 PM Thurs. 31 of May 2016):
I made my model bigger in Blender (didn't care much as right now I'm just testing). Then, proceeded to export it via the Source Export Tools to a .smd file (needed to produce the final file).
Then I wrote the .qc and there's this line called $scale.
I tried to change the scale with a table of proportions I came up with. It changed the model size. But not to the expected size. Also, the X and Y axis that were the same in lenght had in Hammer different size. I expected it to be equal in lenght, not to have different sizes.
Then I modified only the blender file, passed through the entire process of compiling it (with no further modification of the .qc file) and it scaled again.
Then I did another test, this time not changing the scale inside Blender but changing the line $scale in the .qc file. It resized again.
So both scales affect the model. The problem is, I don't know how I am supposed to export them proportionally. One scale, in Blender, was enough to drive me crazy, now I'm just giving up with two. More, when I have to calculate to my guess the scale in the .qc file.
There's another thing; the 2D view grid. It's almost endless. So if I try to measure using the grid I can, because if I zoom, it resizes again to a smaller scale. I can't therefore measure how much of those "blocks" I need to build the model in the proper scale.
A quick related question; does importing to UDK has similar problems? Or I just have to worry about the scale in Blender only? I know quite well the Hammer Editor but if this can't be solved I guess is better to switch.
Fun fact: I just wanted to create a mere dispenser soda machine. Not even a player model.
For example; it might read alyx_vance.mdl
Unfortunately, Blender's U.S. measurement (called 'Imperial') is not the same size as Source's, even though they're both technically the same thing.
Make sure to apply rotation, location, and scale before you export from blender.
https://wiki.teamfortress.com/wiki/Hammer_unit
https://wiki.blender.org/index.php/User:Fade/Doc:2.6/Manual/3D_interaction/Transform_Control/Reset_Object_Transformations
In the "Properties" panel click on the "Scene" tab and then you can switch things around "Units".
If you didn't know this befor I would guess this could help with calculating resizing factors for other programs.
+1
This is very important as it can cause all sort of issues if you don't.
I don't know about either the Source Engine or UDK but Unity has import settings for all models. This allows for easy resizing of any model within the actual engine, I'd be surprised if UDK did not have something similar.
Slightly off topic but...how is it when you have several instances (Alt+d) of an object that sligthly vary in size and location, like stalactites.
You cannot apply anything to instances, but from what I read (and partially experienced) duplicates with Shift+d should only be used in small amounts.
Alt+D is linked so any change to one affects them all, shares the same data set so only one footprint regardless of how many you have(saw a guy use this for thousands of trees on a mountain with an average system).
I use whichever one suits my needs the most. For a base of a similar but different object I might copy with Shift+D and work from there.
If I have many objects that should all remain exactly the same I will use Alt+D so I don't have to edit countless iterations of the same thing.
I would not say to avoid one or use one more than another, only to use the one you need for the job :)
I was a bit confused for a moment and was asking myself if something has changed between versions. The last time I worked with it, the instances were only affected as a whole if I changed the original object and not when just changing a single instance. But after a quick check in Blender it seems I just misunderstood you. ^^
But this is more or less what I was interested in. Some modifiers, like the "Ocean" modifier specifically require that you apply at least the scale.
So, I was wondering if you have an instance of an object that uses such a modifier and if that instance has been scaled, if the modifier still works as intended.
But, if I understand your answer correctly, you just have to make sure that the modifier works with the original and then it doesn't matter how you change the instances.
Thanks again. :D
That last part you spoke of is actually my biggest problem, deciding what suits the situation best. :D
The vertex count of a mesh would be a good example for this...
It does not matter which instance I pick to change on my Dalek model, they will all change as a result(used linked for the domes on the Dalek skirt). I've never used the Ocean modifier so can't comment on how things would work with it... But when I link I no longer see anything as being an original, I see them all as instances of a data set that the original made(if you see the difference).
Vertex count of a mesh is dependent on so many things. It all depends on what you are going to do with it after, game engine, platform, etc...