For now it isnt really something TB really needs, dont encourage the people to keep focusing on 3d items when we need to solve more issues like the increbidly great learning curve, the amount of people quitting for the lack of features, people quitting because of the alts, people quitting because of the lack of friends they have in this game.

TLR We need to work on keeping our members first before we focus on aesthetic issues like this.

That being said, Not Supported as far as the moment goes. Maybe some time in the future. Just not now.

I see what you're saying, to an extent, but I'm pretty sure that simple translation of a complete model is among the simplest 3D transforms. It'd require adding a little bit more to the rendering code, but essentially having an ingame option that it gets shifted 0.02 units up before any rotation seems like it'd be simple enough to implement.

This data could be stored in any number of formats, but we'd definitely not store it baked into a final .obj. That is just asking for trouble.

Unless the render and object code is completely spaghetti, this actually seems like it would be relatively reasonable to implement. I can't imagine there's many reasons why scaling and positioning shouldn't be possible to implement in game.

But no, you'd never store this data by baking it into the .obj, that'd be miserable.

The actual data required would be something like...

<number of objects affected>, could be stored as 1 byte.
<number of transformations on object X>, could be stored as 1 byte.
<transformation type>, could be stored as 1 byte for (0-255) options.
<xval>, float (4 bytes), x position for translation, x factor for scaling, rotation about the x axis stored in some format for rotation.
<yval>, float (4 bytes), same as x but for y.
<zval>, float (4 bytes), same as x but for z.

Set up customization options so that the maximum number of transformations per obj is fixed. The number of objects is always fixed.
5 objects, 5 transformations each, gets you 306 bytes of data that would need to be transferred in addition to the original .obj files and everything.

306 bytes of data, per player, shouldn't be an issue. This post is longer than 306 bytes by a fair margin.

We already have items that can accept text fields (collector's cards). Assuming said system can accept arbitrary text values and it can accept 712 bytes worth of text, then we can even store this in hexadecimal in a text field in the database attached to the 3d object. If that text field is already being used to name the .obj file, add a delimiter and add it on and we still end up not needing to even change the database.

This is possible, if the game can be coerced into doing arbitrary transformations in the order provided on an object per player.

e: Though if someone does use float, make sure it's consistent across OSes, and if it is being stored in that really minimalistic fasihon please provide a nice dandy customization editor in the Torishop, or better yet, in-game and synchronized with the ToriShop.