Shaders
If you have been writing PostFX shaders in Virtools, you may have waited long for this, but here it is: overriding techniques for rendering into RenderTargets!!! You can has Tron, yay! Here's a simple example for a masked glow PostFX:
Overriding techniques allows you to specify a technique name that shall be used when rendering the scene using the Render Scene in RT View BuildingBlock. Previously one was only able to use one shader/material for all objects. That's ok for some tasks but if you need need per-material masking, there was no easy way for doing so. I first expressed the need for a better way in 2005 - that's 4 years ago! In 2006 I tried manual techniques switching and hit another barrier. Now, finally, it's a smooth process. Better late than never!
Some help with hiding or unhiding elements of the scene (i.e. something like RenderLayers) has unfortunately not yet been added. Also some other aspects like include management still needs improvements.
There are a few new shader semantics available:
AlphaTestEnable, AlphaBlendEnable, AlphaRef and for OpenGL only: SingleSided, DoubleSided
If you check the SDK, you will find traces of WIP (work in progress) for shader-based shadow maps: a new shader semantic, a new BB, a new Rendstate and maybe a future built-in shadow-shader. You will also notice that support for hardware shadow texture formats has been added.
LUA
LUA has been added as scripting language. LUA is a widely used scripting language in the games industry. In contrast to VSL (Vitools Scripting language) LUA is not strongly typed and not JITed (Just-In-Time compiled). It's therefore to be considered to be slower than VSL. So why add it? VSL is very focused on implementing new BuidlingBlocks via scripting. It's not very strong with custom data types and working in a global scope is very limited.
Moreover not everybody likes to use the concept of Schematic Programming. By using the SDK it's possible to bypass it, but of course it makes development slower again. Using LUA one is now able to script a game without using the schematic a lot. This is possible because all LUA scripts share the same context. ( A bit of schematic is still a required though).
As LUA is known by a wider audience, new (script) developers can pick up 3DVIA Virtools much faster without worrying a lot about the schematic. A good example for this are the 2 last adventure games by City Interactive. Moreover there is a new example game (a BoulderDash clone) entirely writtin in LUA. I think it's also a good starting point for Virtools users that still need to learn LUA!
As LUA is a dynamic language there is no help from a compiler but a button for checking the syntax is available. Setting breakpoints and stepping through the code is possible! There is a small input field in the right side of the toolbar for calling LUA functions directly but i think it's a bit small. From my Maxscripting experience a big input console that allows to prototype interactively is a big plus and hopefully it will come in a later release.
You can't yet use LUA for action scripts and therefore you don't have direct access to the selection. But using the run-button LUA scripts can be executed at any time in authoring mode too.
Personally I am not much attracted by the LUA syntax. Further more I saw some articles on how to implement OO in LUA and they scare me off 
Currently I think using C# as embedded scripting language is my favorite! AngelScript recently got simple inheritance and interfaces - it's also a strongly typed language with JITC - might be an interesting alternative to LUA and Co.
The LUA editor control is the same from the shader editor and VSL editor and thereore suffers from the same problems i.e. long scripts slow the entire editor down (due it's slow syntax highlighting I guess).
Blend Shape Support
Blend Shape Support basically means morph targets mixable with skinning (bone-based deformation). So you can have facial animation or body deformations/customizations using morph targets ( blend shapes in Maya) at the same time with your standard bone-based character animations.
Probably most people will think "finally facial animations!" … yeah, cool … but I think you can do much more with it…
What about muscle deformation? Here is a simple example of what I mean: an arm deformed by bones can be morphed simultaneously to bulge it for the muscles effects …
Above you see two arm entities, both are referring to the same mesh, but one is using the morph weights differently. The great thing is: it's still only ONE mesh. You don't need to copy the mesh for each entity! Thus it even works independently for GPU skinned characters - only one mesh and full individual weight control .. I tested it and it seems to work!
Currently when exporting from 3ds max, you need to do a "export selected" that excludes the morph targets otherwise they will be added as additional body parts. Hopefully in future those will be detected and skipped automatically.
I think this is probably one of the new feature that really gives a solid advantage over other 3d authoring solutions! Flexible and simple workflow, nice!
To be continued …
There are more new features but it's getting late (bedtime!). Please note that this is beta experience and some things might be different with the final release. I hope it gives some more insights about 3DVIA Virtools 5's new features as benefits are not always clear via a plain listing of "what's new?" items. Feel free to add informations or to ask questions. Till next part, cheers!
Just a little hint for new Unity users on the PC platform. The SciTe/Scintilla editor that comes with the PC version is probably a lot better than the smultron editor that comes for the Mac version. Still it's a complete different level if you use Visual Studio.
Visual C# Express 2008 is a free development environment and it's very good. Besides standards like Syntax-Highlighting it has good refactoring tools and a pretty good intellisense (intelligent auto-completion).
In order to use Visual C# Express, you need to add references to the Unity DLLs inside a new project. On the PC you can grab them from the installation folder
…\Unity\Editor\Data\lib\
The DLLs are
UnityEditor.dll
UnityEngine.dll
If you also add all other DLLs your code depends on, you can even compile your code for verification. If you don't copy your .cs file but use the same that is referenced by the unity project, then each time you save the file in Visual Express, Unity will notice the change and reload and compile it using Mono.
Visual Web Developer 2008 Express says that it has "JavaScript IntelliSense" - I haven't tried it but if you prefer JS than you should give it a try!
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.
CGGenie did an interesting survey called "Upgrades09". After having published the results (see previous link), they also added a very interesting article about how to interpret the results!
It's title: "CG Survey: a question of cost and satisfaction".
To resume the article and the survey, one could say: professional users are less satisfied with their tools than hobbiest or casual users.
Here some extracts:
3ds Max's users have invested a large amount of money, are likely to be professionally pressured in their usage and timescales and also are likely to be pushing the software to its limits every day.
[...] in more challenging ways and those little niggles might become major blockers, those quirky crashes become fundamental cash burners - even though the actual reality of the event, the flaw or the software limitation wouldn't have changed, the user requirements would have.
This helps to understand why a diversified, professional user/customer base might seem always as unhappy grumbler. They use the tools under tight time-frames and budgets. Working with their tool everyday they see what works efficiently and what not. Moreover, they want to push it to it's edges. They want to be fast(er). And if the tool improves, they move fast towards the new 'edge' … pushing it some more! And moreover not necessarily everybody is pushing it into the same direction …
Obviously it's "a far greater challenge" to satisfy those people.
A few years ago, when Advergaming slowly became an old concept, the topic of "Serious Games" started to get some drive. I was looking at some of our projects and said to myself: "hey we actually do serious games, too!".
We never liked the term "serious games". I read that there were discussions about it but still "serious games" is mostly used. Our key idea for learning via gaming is, that the learning process is built-in, not obvious. You just play and somehow without noticing you learn new things. I mean, that's actually a natural element of a game anyways: there is some kind of challenge, because if it's too easy, it's no fun. If it's too difficult it's no fun!
Moreover, game-makers know: players don't like to read pages over pages on how to play a game (in general, there are always exceptions!). So there are many games out there with in-game tutorials, so it's learning by doing in many cases already. Learning by doing or learning by exploring …
So therefore we prefer the expression "Game Based Learning" (GBL) or to be more precise "Digitial Game Based Learning" (DGBL). It's very different to "traditional" eLearning. eLearning still contains a lot of the old spirit for non-interactive teaching methods.
I looked at some other projects and I realized that some were different. They contained more "realism" and they fitted more the idea of "training". It also requires tools to measure and report improvements in a formal way. A game score alone might not be enough. I like to use the term "Computer Based Training" (CBT) for these kind of applications.
Game Based Learning and Computer Based Training are different but you can gradually mix them. Nowadays I usually put them on a imaginary slider and I mix between them based on the requirements and aims.
GBL <——0—-> CBT
For GBL fun is the priority. Reality is not important. For CBT reality is more important and therefore fun is not the key element. Usually CBT are more VR-like (Virtual Reality). If you work in this domain, what terms do you use and/or prefer?
In January I started a little fun project to continue learning C#. Using MOGRE (Managed Ogre3D) and WinForms I started a little editor. It's really at a very, very early state and currently I am too busy to continue working on it, but I have to say, I enjoyed working on it so far.
C# and WinForms make things really a lot easier (I don't like MFC!). And I have touched only the top of the Iceberg so far. C++ is powerful and gives a lot of freedom. Lots of freedom = lots of choices = not always easy to make a choice. I enjoy having some "standard solutions" in C#, like delegates. Built-In Introspection/Reflection/RTTI is also really, really, really cool!
As everything is also of type "object, I believe that node-based editors/programming should be much easier/faster to realize using Dot.Net/C#. Sure, if you need to be portable and if you have to squeeze out the most of the hardware, C++ is the choice. If you do some PC-only Sims or Viz and you don't mind wasting some CPU power, why not? There are not yet many 3D render engines available, but they start to appear (i.e. XNA based).
At work, I decided to implement a (non 3d) project in C#. There are a bunch of asynchonic ways of doing things, and for me it's not so transparent yet (what happens in what thread, what is threadsafe especially when things get layered). But I guess it's a matter of learning and understanding the framework.
Most of the time I am using Visual Studio 2008 Express and for a free tool it's impressive. It does now do lots of things too that previously was only possible using 3rd party Add-Ons like VisualAssist. Something I am missing is to be able to filter the intellisense drop-down list by type (Property/Event/Method). VisualAssist has some filtering buttons at the bottom and it's useful.
