Last time I gave an overview on what VBuilder is and how it improves iteration times. This time I'll give a small example by showing some extracts of what it takes to setup a project.

VBuilder is driven by commands coming from an XML file. Here is an how this can look like:

<!– register data resource –>
<register_dataresource xsrc="demoproject.rsc"/>

<!– load the cmo –>
<load_cmo xsrc="../CMOs/main.cmo"/>

<!– execute build process –>
<execute_script name="INIT"/>
<execute_script name="Load Buildings"/>
<execute_script name="Load People"/>

<!– set the save options for images and sounds –>
<set_save_options name="images" value="IMAGEFORMAT"/>

<– save to VMO –>
<save_changes name="content/demo.vmo"/>

So first one or more data resources are registered. Basically it's adding the search paths for external resources like textures and audio. Then a CMO is loaded. It contains the import and processing logic which then gets triggered. Usually you have textures outside but if you want to include them for the final file, this can be done like shown above with the save_options commands. At the end the new VMO, that includes freshly imported assets, is saved and can be started ie.e with the webplayer.

Btw. VBuilder also supports commands like setting values for script-parameters – very useful for making sure that debug-information is turned off for release builds!

So how does the assets import looks like? Well, this is adjustable to your needs but here is how I often do it:

So basically it's a scriptable build pipeline. Some people asked in the past years what we do and here you got it finally unveiled. It's actually a pretty simple concept and similar to bigger gamedev projects. I could bring it even closer to traditional gamedev projects: a future version could detect what files changed and only process those. That could be VBuilder V2.

Feel free to contact me about it, if you're interested to use these tools. I say tools, because I would add BBs like the Directory-Parser which is especially useful for projects that did not license the XE player.

In early 2006 I started to rethink the build-process for 3DVIA Virtools projects. It's a topic where many people from the Virtools community dive into one day or the other.

The problem

The standard method of doing an assets update for your project is, to let the 3d artist export the new assets versions, then a Virtools developer drops them into the CMO from the resource database and chooses what to replace and what to keep. One by one….

Some developer used custom scripted loading processes and so did we. We used text files and assets loading buttons for some projects. Text contained data of what material or mesh uses what shader and what attributes. But it came out that updating/maintaining those text files was quite error-prone and somehow not really artists friendly. Moreover building the final product for testing still required a bit of the time of a Virtools developer … time that was better spend on bug-fixing or adding features.

The solution

So, the new iteration was a command-line tool we created. Currently I am thinking about a new, better name. For now I will refer to it as "VBuilder". It's a one-click processor that is able to produce VMOs from CMOs using a list of simple processing-commands inside a XML file. A different XML file can be passed to the tool via the arguments, so it's possible batch-build for different VMOs.

We started to use directories as rough top-level for classifications of 3D assets: roads, buildings, cars, people. Adding a new car or a new building became a simple task: the 3D artist exports his new car as NMO to the "cars" directory, then he triggers VBuilder and within minutes a deliverable VMO file is available for testing.

What it requires though, is some up-front import-pipeline coding inside Virtools for each project (which might be reusable for different projects) and – in our case – naming conventions for objects and materials inside 3ds max etc.

What effect did we achieve with this?

Initially we had an iteration time of aprox. one day. This has to do with the fact that a Virtools programmer is not always available or ready to interrupt his development work for an assets integration-cycle.

So the artist may come to him and say: "Hi, I updated some buildings and some cars, can we have a look at it?". The programmer responds: "Let me just finished this little script first. It will only take 20 minutes" … … … then 2 hours later: "Ok, took me longer but now I am read… ???!! Hello?" – the artist went home as he comes to the office a lot earlier than the programmer!! He then does the integration and writes a notification about it. Next day, similar procedure. You see, this scenario really may happen and if you have a lot more Gfx ppl than coders it might get worse. I remember one project, where we had a junior Virtools developer doing mostly one thing: reimport new iterations from the graphics team.

With VBuilder the iteration cycle, for already available content-types, went from worst-case one-day to worst-case 5 minutes. Sometimes it only took 1 minute including startup of the player for testing. The best thing is, it even scales. I was able to support eight 3d artists while having time for adding features or doing bug-fixing. They were doing their stuff and it only needed my involvement when new item-types had to be created.

So with that team and VBuilder we were able to theoretically have several hundreds of content-update iterations or content-extension iterations per day! No idea how many they really did but they did plenty. That's a boost, ain't it?

Interested?

So, after 3 years beeing in use I am considering making it commercially available. It's no magic tool but it allows what I have described above. If you have several 3D artists in your team and you want to free programmer resources, this might be something for you! For me the effort to make it available only makes sense, if there are several teams or people willing to buy this. Thus if you think this is something for you, get in touch with me. Write me an eMail with "VBuilder" as subject. Also let me know what you think of what would be a fair price for you and on how many machines you would like to run it on.

Making it even better

I have a couple of interesting ideas of how to bring VBuilder to the next level. Currently it's focus is triggering the import and processing and building VMOs. This has some backdraws when working with the CMOs inside Virtools "Dev" and I think there are some interesting ways to make it even more efficient. If there is commercial interest, I would bring VBuilder to a new level!

To be continued …

Now this gave you a rough idea what VBuilder is about. In the next part I'll go into some details on how exactly it works.

Recently I was asked how to use global variables inside global functions using VSL, one of 3DVIA Virtools built-in scripting languages.

In VSL you can share a variable across diferent "Run VSL" BuildingBlocks by using the keyword "shared". For example

Besides using VSL in BBs or actionscripts, you can also create "global" VSL scripts. These are automatically included. The things is that you can not use the shared keyword inside global scripts. So if you want to modify shared variables inside global functions, one workaround is to use parameter-objects.

Basically it's a struct containing variables you like to share. Either one struct for all or split your variables by context into different structs. This user defined structure makes passing them to functions much easier. Also less code changes are required when adding more data.

Above you see the definition and how it's used as input parameter of a global function. This works because it's passed by reference and not as value (/copy). This way you can modify shared variables even inside global functions. Here is how it could look like inside a VSL BB that calls the global function:

I hope this will help a few more people. If it's not clear, let me know.

Last august I finally took some time to try an idea I had or a while (years?). Would it be possible to mis-use 3DVIA Virtools Point-Cloud system for rendering foliage objects (grass, flowers, plants etc). Basically, Point-Clouds are used to visualize 3d scans or data. It's a feature that was slowly introduced with 3.0 Service Packs and finalized in 3.5.

It comes with a feature that is called "Point Cloud Selection" which allows to render separately a subset of the cloud. Interestingly you can also render meshes instead of sprites. This, plus being able to use shaders with point clouds gave me the idea that it might be useful for outdoor foliage rendering.

I'll make it short: it doesn't work the way I hoped.

If you try to render a selection with meshes using a shader, the whole system slows down intensively. I think it's a combination that was not considered or intended by the developers. So it's only compatible with the fixed function GPU pipeline. Besides that I am not sure what it takes to calculate the vertex positions inside the shader correctly, so a mesh is rendered at each point position.

In addition to that, the bigger the cloud is, the slower is the selection process itself. Thus you cannot have one point cloud for your entire outdoor scene – you would have to manage multiple clouds via a grid, nullifying somehow the benefits of this out-of-the-box selection-system.

Here is a picture where on the left you see the whole point cloud and on the right you see a circular selection around the character:

Of course, there are other methods to do the same. Justed wanted to see if it goes also like this. 🙂

For a couple of years now, I am "misusing" Characters for a lot more than "just characters". For those that don't use Virtools, a Character Entity is a 3D entity that has "bodyparts" entities. A bodypart can be a bone, a dummy or a an entity with a (skinned) mesh. You can also add all kind of non bodyparts to the hierarchy.

The interesting aspect is that the whole combination can be treated as one. In the 3D layout window, you usually pick the character entity and thus you translate the complete set. Moreover there is a character parameter type, thus you can search, store, hide etc the whole complex as one.

Office chairs, where you want to be able to change the height or rotate the seat, are a simple example.

Last year I had a combo of particles systems that I wanted to treat as one unit. Easier as asset and easier to create, duplicates etc. Thus I wanted them to be part of a Character.

(Edit: the following passage is not entirely correct, see notice in bold that follows)

The first thing you may notice is you can't easily create any characters or bodyparts inside the Virtools authoring system. Even via the scripting language (VSL) one is not able to create such objects.

Missing VSL bindings is still a problem in Virtools (although things got better). We have a custom DLL where we do our own bindings in these cases, but I wish I would not have to waste my time on this. After I was able to create Characters and bodyparts via VSL I saw that the Level Manager didn't update it's character content. I don't know yet what kind of notification it requires but saving and reloading the file (or asset) fixes the problem.

( EDIT:  as pointed out by Julien in the comments, you actually can create characters and bodyparts using bc.CreateObject – just like in the SDK. There's are only no shortcut bindings like bc.CreateEntity3D )

On my first iteration I simply added the particles system dummies to the character hierarchy, but they also were listed separately when loading them at runtime. Unfortunately you can't attach the particle system components (building blocks) onto bodyparts but only onto so called "3D frames" which are the 3d dummies (/gizmos) of Virtools.

"Hey wait!" came into my mind – 3d dummies in Virtools are 3d entities with an additional flag and bodyparts are special 3d entities. So I did the hack: added the flag to my bodyparts and suddenly they accepted the particle system buildings blocks!

I wrote me a little action script that creates a "particle character" from a set of distinct particles systems. I have no idea how solid this is, but so far no complains from the customer! Hehehe …

😉

It makes it much easier to move, load, store particle-system combos (only textures need to be selected manually in some cases).

I wanted to expand an import pipeline for characters, so they use GPU skinning. Unfortunately there is no BB and no VSL binding for this. Luckily it's possible using a custom BB.

You need to add this flag to bodyparts:

CK_3DENTITY_HWSKINING

I am surprised that this is not bound to VSL. Nobody ever complained about it?