Sorry your browser is not supported!

Just wondering how the scale of created 3D objects works in DB. I'm working on a program to create objects to be used as props in games (tables,chairs etc). Is there any specific scale that I need to stick to ? Are the objects in the DBPro example media folders the correct scale and should I base my scaling on them ? Or is it safe to scale down any oversized objects within the DB code?

The best plan is to scale one unit in world space to a unit in reality. One unit equalling one meter is fairly standard for FPS and man to man combat games. But, one unit could easily be centimeters or kilometers depend on the game.

Of course, the rules are even less strict for arcade games where consistency of presentation is more important than reality. For example, in Ice Snake I have a miniature soccer field with giant (relative to the field) soccer balls. That's because the purpose of the soccer balls is to hide mines and berries and not simulate a soccer game. Soccer is just the theme of the level.
--
TAZ

That's pretty much how I plan to do things if I'm creating all my own objects. However, what happens if you use a separate program that outputs, say, a large terrain. Then from another program that specialises in houses/architecture you build a house. Inside that house you require a person, built with some character maker. Once all loaded within DB the character could feasibly be bigger than the house and even the terrain. Would simply scaling everything down/up to the right scale in DB solve this without messing up textures/limb offsets etc ? Or would it be better to output each object from their respective programs at the same scale, if possible ? It's just something that's bugging me, though it might well be irrelevant.

While you can scale object in DB, I've heard of people have some problems. So, given the choice, I try to build the models in scale in the editor. One trick is to make a 1 meter cube in DXF. Almost all modellers can read this format. For each project, import the cube as an object and build the model relative to the cube. When you export to DB, all the models should be in scale to the cube.

There's always going to be a little trial and error, but with a little planning and building a few test object before hand it will help you to iron out any issues.
--
TAZ

[edit for clarity]

Yes, good system. I think I'll stick to that from now on.
Much obliged Z.

The original scale in which the models were built is a factor for DBP. I bought 3 different collections of models from a company named geo-metricks: a collection of low-poly tanks, another of historical structures (buildings, bridges, towers, etc.), and finally a collection of 24 human figures.

If I bring these models into DBP and show their unit sizes [x,y,z] the tanks are usually on the order of something like 100,50,50. The buildings and humans though, are more on the order of 1, 0.5, 0.5 (50 to 100 times smaller).

While I can bring any of these into DBP and scale it so it "fits" in my world, I have a lot of trouble with the smaller-scale models. That is, the tanks look and work beautifully, but the smaller-scale humans and buildings are problematic. They don't always texture properly and in cases where the jointed models (the humans) are used in animations, things don't always line up properly when a joint is rotated. Or sometimes they don't line up properly "out of the box". Many of the models look "exploded" in the Pro version of Dark Basic, where each limb is clearly not visibily attached to a parent. Rotate a given limb though, and any sibling limbs also rotate as you would expect (for example, rotate the left knee and the lower left left and foot also rotate even though they don't seem to be visibly attached to the knee). The SAME MODEL in DB Classic, however, doesn't have this "exploded limb" problem -- all the limbs look to be attached properly.

I have reason to believe collision detection might also be a problem, but can't prove it yet.

If I bring the smaller scale models into a modeling program and resize them, these problems seem to go away. For example, if I load a tiny 1.5 x 1.5 x 1.5 unit gothic church into Gamespace, resize it to 150 x 150 x 150 and save it, I can then texture it as you'd expect in a DB program. I can scale it and the textures still look fine. If I try it with the original, smaller-scale church, I can't texture it properly to save my life, even if I scale it upwards in my program. It reminds me of truncation errors in a program that deals with very small floating point numbers -- like maybe the UV mapping is trying to reference coordinates so small they take 6 decimal places to express, but somewhere there's a limitation that limits us to 4 decimal places.

There is a reference in either the DB classic or Pro help files (sorry, I can't remember which) that discusses unit size and warns to expect trouble with a model less than 50x50x50 units. I think it hints as to why this would be, in terms of DB's internals and how they "talk" to DirectX, but then again, maybe I was really drunk and dreamed that up.