Drawing to Architectural Scale

Been a long time since I've used 3DGS.
I'm trying to convert actual scaled floorplans to 3DGS.
What's the best way to do this?
I seem to recall a quant (quake unit?) is about 2.5 inches, but I'm just not sure.
So, how many quants = a linear foot?
Or is there a better way to do this.

Thanks in advance,
Neut.

gs manual recommends one inch per quant for person-based games and 4 inches por quant for vehicle-based games

Thx painkiller!
I *did* RTM the manual, but couldn't find *that* particular info.
(of course I could have read it, and skipped right over it - getting on in years I guess...)
I would like to design this without having to use scaling of any kind.
Do the ratios you (ahem, the manual) advise accomplish this?
I have to keep all the texturing in mind too...

Thx again!

I don't understand the problem, why don't you just choose a scale yourself?
My player models are usually ~ 0.5 - 1.5 big grid boxes (in WED) in height (that is 128 quants for each box). There is not really such thing as a wrong scale, just keep it above a certain value (I would not go below ~32 quants for a meter) because of inaccuracies of "var" and below a high value (one meter should be less than ~1024 quants - just a guess) to avoid overflow in calculations.

I'm trying to avoid the scaling math calcs for faster framerate.
Now maybe I'm wrong, but my thinking is if the level is designed where all objects are scale=1 (and textures are mapped that way), I can avoid some extra math for the engine.
I could be wrong, scaling could be integrated in the render pipe and there's no way to avoid it.
I'm hoping when the engine "sees" an object of scale=1, it bypasses the scaling math - of course it may not work that way and perform the calc anyway.

I don't want to use scaling just to make things fit, or be a certain size when rendered.
I think that should be taken into consideration during the design phase of a project.

Thx Superku...

avoid scaling math calcs for faster framerate?
bypass the scaling math?

I am completely lost there... If that is true someone please explain this to me.

I thought changing the scale of static objects (like your buildings you are trying to scale) had 0 impact on framerate beyond the initial loading of the objects.

P.S.: I also dont understand the topic of the thread very well. The size of your objects only matters relative to the size of your other objects. I think there is no "correct" scale for your buildings other than the scale you want to choose.

P.P.S: Just to test I loaded a level I had previously created, but with everything 5 times larger... The result had zero impact to framerate.

The check would be already slower than just scale anyway. Here is how the code needed to look like:


It needs a function call in the worst case (although I'm sure that an inlined version of fabsf() is used), it needs a roundtrip to the FPU (to calculate scale - 1.0f) hence the precision problem of floating points one can't just compare both values without false/positives and then you need a conditional jump. And this always, no matter if the scale is 1 or not. Not to mention that fabsf() also needs to check the value (and here comes the second conditional jump) and then do a bit operation on it to negate the value if needed.
Just calculating this always only takes a roundtrip to the ALU which can process a multiplication by 1 extremely fast.

Thankyou for clarifying that for us

Wordy, but here we go... <sigh> ....
I'm talking about the math in the 3D engine itself, and not about script or LiteC commands (sorry if I didn't make that clear at first).
Take any square cube (8 vertices) - for each frame rendered, that cube has to have its 8 vertices scaled, translated (moved), rotated, etc, etc...
Then the surfaces are constructed, then the textures are mapped to the surfaces.
If you scale an object from its creation (when you designed and made it - not when did a Load Object) say by .5 (smaller) or 1.5 (larger), you have now forced additional math mostly on the texturing side IMHO.
Using the .5/1.5 example above for a 16*16 bmp, the bmp itself has to be resized before mapping - .5 scale would require bmp reduction to 8*8, 1.5 scale would be a 24*24 bmp.
BUT - this is not just straight clipping or multiplication, it's *resampling* the entire bitmap.
How many of us *really* use a 16*16 bmp (256 pixels), eh..?
More like 64*64 (4096 pixels), 128*128 (16384 pixels),or 256*256 (65536 pixles).
Yes I know you can use any "factor of 2" - 8, 16, 32, 64, etc.. and this probably exists in the first place because of the algorithm used for resampling.
Any resampling takes time, and IMHO always clobbers the detail of the bmp unless it's just a "flat solid color".
So, any thing you can do to keep from scaling an object from its creation avoids additional math, and "fuzzing" the texture.
And I do mean "fuzzing", not an obscenity alternate - although either would appropriate for what it does to a really "crisp" texture <grin>.

So if I (or you) design an object at its true "run-time" size to begin with, so you don't have to scale it to make it fit or look "right", it should avoid all the crud I babbled about above...

Of course I could be dead wrong about the whole dang thing, proving myself a ditz. ("again" as my wife would add...)

-Neut.

You are because that isn't how graphic engines work at all.

To put it in a few sentences:
The engine isn't re-calculating the size of a bitmap at all.
It simply places it on the surface, and then(!)
it translates the places of the pixels to the pixels of the screen, depending the position and arc of the camera...
The reason for unsharp bitmaps is the - intentional - mipmapping.
This means the pic is precalculated in different sizes, where the engine chooses the appropriate size depending the distance and angle of the triangle in relation to the screen.