View Full Version : Lightwave scale
philnolan3d
06-28-2007, 04:20 PM
I'm trying to figure out how I should scale something in Lightwave so that it will match up with Unreal. I saw this line in the NewTek Tutorial as well as another tutorial. It doesn't make any sense. "one unit in UnrealED corresponds with 1 m in LightWave. A character in Unreal Tournament 2003 is 96 units high (approx. 2m)." If 1 Unit = 1 Meter, then 96 Units cannot = 2 Meters.
DGUnreal
06-28-2007, 06:27 PM
In the UT2004 implementation of UE2.5, the measurements are approximately:
16 unreal units = 1 foot
52.5 unreal units = 1 meter
However, most map objects are scaled oversize to accomodate game play, such as double-jumping, quad jumping, etc.
So you would also usually scale the world objects to 1.5 or 2 times larger than real world.
philnolan3d
07-01-2007, 11:45 AM
Are you sure it's 2.5 that comes with UT2004? When I load UnrealEd the splash screen says 3.0. I've been going by the scale above but everything is like a 3rd of the height it should be once it's imported to UEd.
DGUnreal
07-01-2007, 01:36 PM
Trust me... :)
I've been working with the Unreal Engine for many years, personally and professionally.
UT2004 uses Unreal Engine 2.5 and Unreal Editor 3.0.
This does confuse some people.
It is because Epic advanced the Editor version independantly of the Engine version.
Unreal Engine 3.0 (for UT3, GoW, etc.) simply calls it Unreal Editor now.
I have both Licensee and other versions of Unreal Engine 3 and the UnrealEd splash screen no longer has the version information, although the editor does retain its build version.
Trust me, the equivalent engine scale of entities in UT2004 is 16 unreal units = ~1 foot. I wouldn't lie or mislead you.
In third-party 3D applications, the general scale should be set to Generic 1 = 1.
Then the Snap Grid should be set to power-of-two values only, such as 1, 2, 4, 8, 16, 32, 64, 128, 256, ...
And all primitives and objects for StaticMeshes and brushes should be created so that they line up on power-of-two bounding measurements (outside edges), so that when they are imported and inserted into UnrealEd, they line up across the grid, can be scaled properly, fit correctly with CSG Brushes, and fit inside of terrain, within the editor.
This is why it is essentially no different creating CSG inside of UnrealEd or the 3D software, they are both set to similar scale and units.
If you attempt to use real-world scale dimensioning in your 3D software it may not work. This is because the "world space" of 3D software using inches or meters may not properly equate to the proper sizes when exported to UnrealEd, since UnrealEd imports as generic units of 1:1 and does not perform conversion from feet/meters to unreal units.
If you attempted to assign some sort of measurement system to Unreal, 1 "foot" being 16 units would give you 16 Unreal inches per "foot". The Unreal scale is more to do with the visual sizing of objects, not a predefined solid ordered measurement since it is not a CAD application. Everything in the Unreal Engine world is power of two because that is the system that computers easily work on.
So set your 3D software to generic 1:1, grid to power-of-two, and create your objects with the general size that 16 units is around 1 foot for players in game.
*edit*
Here is a good link. UDN StaticMeshes TOC (http://udn.epicgames.com/Two/StaticMeshes.html).
In particular, see these subtopics (especially those marked):
- BreakAway Example
- CAD to Unreal
- Collision Tutorial
- Converting BSP Brushes is Suboptimal
- Intro to UnrealEd
- Level Optimization
- Level Optimization StaticMesh *
- Lighting on Surfaces *
- No LOD on Hardware Brushes *
- Runtime Map Process
- StaticMesh Collision Reference *
- StaticMeshes Tutorial *
- Workflow and Modularity *
If you haven't been to Epic's Unreal Developer Network, this and UnrealWiki should be your first stops when learning how to map.
philnolan3d
07-01-2007, 05:11 PM
I have been to both the UDN and UnrealWiki. So I didn't mean to imply you were wrong or lying, I just thought you may have made a mistake when typing it or something.
Unfortunately for this case Lightwave only uses real world scale, the choices are Metric or English and unfortunately no snap to grid. What I had done was create a large square polygon and subdivide it to make 1' squares, then used LWCAD's "drag snap" tool because it will snap to points on a background layer.
I'll check out that link. I'm even more curious because I know a LOT of Unreal maps and meshes have been made in Lightwave, so there must be some trick to it.
I've only been using UEd for a week, got the majority of my knowledge from the Buzz3D videos, plus I read through angelmapper.com
DGUnreal
07-01-2007, 05:37 PM
Hi Phil,
My comments were not meant to be inflammatory.
I was only stressing that I wouldn't be mistaken, leading you astray, or pulling your leg. :)
Lightwave only has Metric/English and no grid with snap?
I haven't looked at LW since the old Toaster days...
Do they not have a Custom/User-defined Units option?
If so, then what you will have to choose depends on the options they offer.
I would require more information...
What file format are you exporting to? UnrealEd wants .ase by default.
The issue will be what float numeric value they are exporting in.
So for example the most likely scenario in LW is: if you choose English Feet then 1.000 LW world units = 1 foot in LW scale, which will export as the value "1.000" in the exported file most likely, and since UnrealEd uses generic units, it will import into UnrealEd as 1.000 which will be assumed as 1.000 Unreal Unit, not the 16 Unreal Units that an "unreal foot" is.
If you follow that...
Which is why you normally work in Generic 1=1 units.
If you must work in Metric or English, then the baseline 1 Unreal Unit is:
1 UU = 0.75 inches
1 UU = 1.90476190476 mm
But working in this manner is going to be really tough.
You could set the scale to English Inches, but then everything you create, you will have to make sure it is pre-scaled 1:0.75. So if you want an object to be a specific size, you will have to fudge it in LW so it ends up correct in UnrealEd.
Your other option is to learn Maya. They have the free PLE version which is supported by UnrealEd.
Most studios are using Max and Maya.
A_M's site is good.
Personally I refer to UDN first, UnrealWiki second, then stuff from my pals Hourences (http://www.hourences.com) and A_M (you apparently already have her URL). The tutorials on my site are more specific actor in-depth technical stuff.
Fordy has probably the best Max-to-UnrealEd tutorial on the web, but that won't help you much.
philnolan3d
07-01-2007, 07:25 PM
Again thanks for the info. I'm not exporting, I just save as lightwave's object format, LWO. I think I may have figured out a bit of a hack in LW to make it snap to one foot grids. In my 5 years of using it professionally I've never had to use any of the grid features. It works a little bit differently than Maya since the grid changes depending on how far zoomed in you are. I do know and use Maya, it's just that 99% of the time Lightwave is better.
DGUnreal
07-01-2007, 08:12 PM
No problem.
Once you get into StaticMeshes (called hardware brushes by some) or if you will be using Unreal Engine 3 where meshes are the main construct type, then exporting to .ase will become necessary.
n-Fusion lists mastery of Max or Maya is a must, so that will determine what app you use.
Max and Maya make up at least 95% of the game studio market for 3d apps, with the others (Lightwave, Softimage, etc.) in use by only a small few.
All of UnrealEd's plugins are developed for Max and Maya, so that sort of forces a person's hand to one of those packages.
The Max grid also changes on zoom level, but that is normal so that the grid maintains a usable snap dimension. ie. if it is set at 2 and you zoom out, it starts dropping back to 4, 8, 16, 32, 64, etc. instead of filling the viewport with a mass of solid gray grid lines that are useless. :)
I'm not a fan of Maya myself. I find Max easier to use, but then again I've been using it since 3D Studio Release 2 (in the old DOS days).
Powered by vBulletin® Version 4.2.0 Copyright © 2013 vBulletin Solutions, Inc. All rights reserved.