3ds max

I have a case where I procedurally create content in 3ds max. Using the quite new feature "RealWorld Scale" UV coordinates I also get usable UV generated. But when I imported the geometries into Virtools, the UVs had an offset of 0.5. I saw that if I turn off the Real World Scale, in 3ds max, I lost that offset. I also tried the new Dev4 Collada import but it seems to totally ignore tiling and offset values. So, here are the code snippets for a quick Max2Virtools.dle source code Mod, enabling RealWorldScale support. I only tested it for my case, so maybe it doesn't work for other cases – in that case it might serve as starting point.

In file export.cpp find the section that looks like this

    //– Apply tiling
    u=-uvgen.UOffset + 0.5f + ((u-0.5f)*uvgen.UScale);
    v=uvgen.VOffset + 0.5f + ((v-0.5f)*uvgen.VScale);

replace it with something like this

    //– Apply tiling
    // dbo 19.07.2007 – when using real world coords offset by 0.5
    // warning – just tested for my case – use this only as a starting point
    if (! uvgen.RealWorldCoords)
    {
        u=-uvgen.UOffset + 0.5f + ((u-0.5f)*uvgen.UScale);
        v=uvgen.VOffset + 0.5f + ((v-0.5f)*uvgen.VScale);
    }
    else
    {
        u=-uvgen.UOffset + ((u-0.5f)*uvgen.UScale);
        v=uvgen.VOffset  + ((v-0.5f)*uvgen.VScale);
    }

in that same file you have something like

    uvgen.AngleMap        = uvs->GetAng(0);
    uvgen.Cropping        = FALSE;
    uvgen.UCropOffset    = 0;
    uvgen.VCropOffset    = 0;
    uvgen.UCropScale    = 1.0f;
    uvgen.VCropScale    = 1.0f;

 append one line so it looks like this:

    uvgen.AngleMap        = uvs->GetAng(0);
    uvgen.Cropping        = FALSE;
    uvgen.UCropOffset    = 0;
    uvgen.VCropOffset    = 0;
    uvgen.UCropScale    = 1.0f;
    uvgen.VCropScale    = 1.0f;

    uvgen.RealWorldCoords = uvs->GetUseRealWorldScale();

In the file Max2Nemo.h replace this

struct TextureUVGen {
    BOOL TileU,TileV;
    BOOL MirrorU,MirrorV;
    BOOL Cropping;
    float UOffset,VOffset;
    float UScale,VScale;
    float AngleMap;
    float UCropOffset,VCropOffset;
    float UCropScale,VCropScale;
    TextureUVGen() {
        TileU = TileV = MirrorU = MirrorV = Cropping = FALSE;
        UOffset = VOffset = AngleMap = UCropOffset =VCropOffset = 0.0f;
        UScale = VScale = UCropScale = VCropScale                = 0.0f;
    }
};

with this

struct TextureUVGen {
    BOOL TileU,TileV;
    BOOL MirrorU,MirrorV;
    BOOL Cropping;
    BOOL RealWorldCoords;
    float UOffset,VOffset;
    float UScale,VScale;
    float AngleMap;
    float UCropOffset,VCropOffset;
    float UCropScale,VCropScale;
    TextureUVGen() {
        RealWorldCoords = TileU = TileV = MirrorU = MirrorV = Cropping = FALSE;
        UOffset = VOffset = AngleMap = UCropOffset =VCropOffset = 0.0f;
        UScale = VScale = UCropScale = VCropScale                = 0.0f;
    }
};

You are ready! Note this is for 3ds max8 and +
If you need the binary for 3ds max8, send me an eMail.

I've seen some interesting Virtools projects where unfortunately the behavioural approach (like promoted by Virtools) is used too extensively with a huge number of objects and lots of scripts. If you have then a look at the profiler you see the behavioural manager is eating a lot of CPU power. Why?

I think it's ok to say that the behavioural manager is currently working a little bit like an interpreter because it needs to parse the graph of BuildingBlocks in order to check and manage the activity states of the linked components. The more deep and nested your graph is, the more it needs to traverse the graph – at least potentially. It depends on the activity states of the links and BuildingBlocks. That's also why you try to separate and wrap parts that are only active once in a while. A manager-like approach (one script handles many objects) might be a better approach for such situations.

Recently I started to read a little bit about (low-level?) continuations and (higher level?) coroutines , tasklets , micro-threads , generators. Some of this stuff was or is in stackless phython. There are some interesting articles in regards of implementing game object logic using concepts like tasklets. Maybe something like a behavioural engine could be implemented using either signals-and-slots or these tasklets and would then probally not suffer anymore from so heavy performance penalties when using lots of scripted objects at the same time. This concept of micro-threads is also used for EVE-online – a very complex MMOG. Some more interesting links:

Game Smart on Coroutines
Multithreaded Game Scripting with Stackless Python
Stackless Python: about Tasklets
Discussion Thread about stackless python, co-routines, micro-threads etc.
Gamasutra: Game Scripting in Python