Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[ErV]

Hello.

I've been working with WME for some time, so, there is a list of all things that could make WME better. (If they are implemented). Some of them are very specific, but... (please don't take anything personally - it's all just my working expierence):

1) Request: type informations in scripts. Or at least some way to extract properties of given variable.
Reason: for example - there is "ShadowColor" property in Actor3D. When I first met this value I've spent some time thinking just about in which way it is stored. Is this an rgba structure (for me this solution looks reasonable)? Or is it a DWORD? And if it is structure what are it's fields - ints or floats?
So I suppose that more documentation is needed, or there must be added some way to specify explict structure of variable.

2) Request: Scripting speedup. Right now scripting is quite slow. 20lines script attached to an actor in some situations can make engine run VERY slow...

3) Request: IWmeValue::GetType();
Reason: It is not easy sometimes to determine the type of variable passed to a plugin from a script. Probing it using ISValInt() of IsValFloat() looks to me as a very strange to do things. Another bad thing is that IWmeValue uses virtual functions. That increases memory usage. What about analog of VARIANT types? Not for structures, just for a single values?

4) Request: LowLevel render access/per actor renderstates.
Reason: It is not possible ANY of standart 3D tricks right now. Not just event a simple soft shadow.
Not possible to do anything! (Sorry, it looks like I'm getting too emotional). During the laast month I've been asked several times about soft shadows. I know several techniques to achieve desired effect (at least five of them), but I was unable to implement any of them due to engine restrictions.  
Even attaching simple custom shadow blob was not possible because it cuts off actor feet due to enabled D3DRS_ZWRITEENABLE. I know that WME tries to be a "High level engine", But (IMHO) it's a bad direction of progress. I suppose that a simple api layere that could help me to change drawing order, to set a specific render-state on per-actor basis, to change render target to something I want to use, to draw custom objects without adding actor would be great.

5) Request: LowLevel scene access. (Lights, geometry)
Reason: That's all comes from "soft/dynamic shadows" request of my customer. When I tried to access a scene information (number of lights in scene, theri names, positions, states, inner/outer radius, type, falloff) I found that there is none available. Finally I wrote a plugin that provides all this information, but, that's certainly just another wrong way to do things. Since information is already stored in engine, isn't it easy enough just to make it accessible in scripts? Just for reading, at least?

6) Request: LowLevel animation controller. (actors)
Reason: It's not possible right now to implement such a simple effect as making actor to look at something. (I do not mean turning the whole body, just the head). I can't parse 3d actors bone structore. This makes many good things impossible. (as well as another shadow-making technique)

7) Request: actor/model/scene loader plugin.
Reason: What about custom model formats? both *.X and *.3ds are quite old and both have large amount of limitations: There is no lights in *.X, and there is no normals in *.3ds, as well as no free spot lights and so on. And, by the way *.X file format gets spoiled by Microsoft with every next generation of DirectX SDK.

Request: hardware acceleration support.
Reason: As I see, currently WME doesn't use fully hardware acceleration (D3DDEVCAPS_PUREDEVICE). I know that there are some specific problems on both ATI and GeForce (point sprites/wireframes on ATi and the fact that there is no indexed Vertex blending on ANY GeForce video card), but all of them can be solved. And hardware support will make run with rocket speed compared with current state.

9) Request: stencil shadows optimizations
Reason: It looks like Stencil Shadows are calculated completely using CPU (I think so because of two times slowdown). There is a good article in ATI SDK "Hardware Shadow Volume Extrusion using vertex shaders". Shadow Volumes, created this way works well even on cards with no hardware VertexShader support. And they are MUCH faster than a CPU runtime-calculated shadows

10) Request: Mesh/3DEntity/static Mesh class.
Reason: Creating  an actor for every teapot in scene is a quite strange way(IMHO) to do things. It looks for me like a way of wasting system resources. I think that having an unanimated static/moveable mesh would be good.

Any comments?

[Mnemonic]

Ok, some comments...

1) Request: type informations in scripts. Or at least some way to extract properties of given variable.

I believe in most cases it's obvious what the property type is. As for colors, all the colors are stored in 32bit RGBA format.

2) Request: Scripting speedup. Right now scripting is quite slow. 20lines script attached to an actor in some situations can make engine run VERY slow...

Do you have any example of such script?

3) Request: IWmeValue::GetType();

GetType() would be certainly possible. Although I'm not quite sure what the problem is here. In most cases when you're accepting parameters in the plugin you know what type you want to get, so you use the appropriate GetValXXX() method and the value will attempt to convert its content to the required type. Alternatively you can implement some method "overriding", like (pseudocode):

if(Value.IsString()) FindNodeByName(Value.GetString());
else FindNodeByIndex(Value.GetInt());

4) Request: LowLevel render access/per actor renderstates.

Should be possible to some extent, but you gotta understand it's not a design priority. Sometimes I feel you'd be much more convenient with some generic low level 3D engine...

5) Request: LowLevel scene access. (Lights, geometry)

Should be possible.

6) Request: LowLevel animation controller. (actors)

Any suggestions on how such API should look like?

7) Request: actor/model/scene loader plugin.

WME needs to be accessible for a large demographics of users, using various 3D packages. Hence the use of commonly supported formats.

8) Request: hardware acceleration support.

Um, I'm afraid pure device is a no-go for lil' old WME.

9) Request: stencil shadows optimizations

But even if the extrusion is done in shaders, there's still a great deal of work that needs to be done in CPU, isn't there? Like.. preparing the model used for the extrusion?

10) Request: Mesh/3DEntity/static Mesh class.

I disagree. You can't just throw in a plain ID3DXMesh (or something like that). It needs to be wrapped into some game object. And why not Actor3D, since it already provides all the necessary functionality? Some "Entity3D" would be internally just Actor3D with a few scripting methods cut off.

[ErV]

Ok, some comments...

1) Request: type informations in scripts. Or at least some way to extract properties of given variable.

I believe in most cases it's obvious what the property type is. As for colors, all the colors are stored in 32bit RGBA format.

Well, i think i've just worked too much with directx, because for me it is not obvious.
The most useful approach for programmer is to declare color like structure - to avoid misc. "<<" and ">>" operation.
Color can be define like this:
struct Color{
 union{
  struct{
   char a;
   char r;
   char g;
   char b;
  }
  DWORD argb;
 }
 Color(char _a, char _r, char _g, char _b);
 ///etc.
}

Color may be rgba, argb, abgr, xbgr encoded. Some of encodings are native in windows and some - in DirectX. I just had no Idea what kind of them you use.

By the way, the color of shadow can be set in two ways - via D3DCOLOR field in vertices, and via material.
And if it is set using material it must be color value, i.e.
struct with 4 floats. And if it is a struct, what names are used for the fields? uppercase or lowercase?
And there is no mention in documentation about what type is used for color.

Also the color is an int (in WME). As you may already know, the size of an int isn't defined anywhere as standart. So it may be 16 bit, it may be 32 bit, and it may be even 64 in some cases. And it can be long and short. So, the question is how big is your "int"? Looking through the code I found that it is, most likely, a DWORD. So it must be 4bytes long. Using of and "int" is quite confusing, believe me.

2) Request: Scripting speedup. Right now scripting is quite slow. 20lines script attached to an actor in some situations can make engine run VERY slow...

Do you have any example of such script?

well, I've killed that script during development, because it was slow.
Here is a rough example of something like this (syntax may be incorrect and it is not optimized, but whould give you an idea about original script):

actor.AttachScript("scripts\shadow_daemon.script"); //actor is an actor3d

//ShadowManager is my class implemented in plugin
global shadowManager = new ShadowManager();

----------
while (true){
    var numLights = shadowManager.GetNumLights();
    var LightPos;
    var noLightFound = true;
    var diff;
    var distance;

    for (var i = 0; i < numLights; i = i + 1){
        Light currentLight = shadowManager.GetLight(i);
        diff.X = currentLight.PosX - this.PosX;
        diff.Y = currentLight.PosY - this.PosY;
        diff.Z = currentLight.PosZ - this.PosZ;
        var curDistance = Math.Sqrtf(diff.X*diff.X + diff.Y*diff.Y + diff.Z*diff.Z);
        if ((noLightFound)or ((curDistance < distance)and (distance < currentLight.outerRadius))){
            distance = curDistance;
            LightPos = diff;
            noLightFound = false;
        }
    }
    actor.SetLightPosition(LightPos.X, LightPos.Y, LightPos.Z);
    sleep(20);
}
----------

there were also color calculations also a distance-based shadow color calculations a weights calculations for determining a stronges light. I just wanted to make it possible to change light color computation callback. Unfortunately, script worked too slow.
If you aren't satisfied with that example, I'll hang a part of C++ code (with same meaning) later.

3) Request: IWmeValue::GetType();

GetType() would be certainly possible. Although I'm not quite sure what the problem is here. In most cases when you're accepting parameters in the plugin you know what type you want to get, so you use the appropriate GetValXXX() method and the value will attempt to convert its content to the required type. Alternatively you can implement some method "overriding", like (pseudocode):

if(Value.IsString()) FindNodeByName(Value.GetString());
else FindNodeByIndex(Value.GetInt());

Well what about conversion routines for a certain type?
(IMHO)The code writting in this scheme makes too much runtime checks. And there isn't documented what happens if I've asked engine for an int, and the IWmeValue is really a string. I had at least one AccessViolation because of this.

4) Request: LowLevel render access/per actor renderstates.

Should be possible to some extent, but you gotta understand it's not a design priority. Sometimes I feel you'd be much more convenient with some generic low level 3D engine...

You are certainly right (about me and a low-level 3D engine), but unfortunately it's not an option. My customer likes WME (and I understand why ), and doesn't want to hear about (making) other engine. By the way It will take to much time to write a clone (three months of hard work, at least) of WME. And that will be a clone without ProjectManager. And it's certainly not a solution to take any risks when project has already started.

5) Request: LowLevel scene access. (Lights, geometry)

Should be possible.

I've implemented this already, it's easy.

6) Request: LowLevel animation controller. (actors)

Any suggestions on how such API should look like?

Something like this:
int ACtor3D::GetAnimationName(index);
int Actor3D::GetNumAnimations();
string Actor3D::GetCurrentAnimationName();
int Actor3D::GetCurrentAnimationIndex();
property Actor3D::DisableAnimationHandling: boolean; //makes engine to stop handling actor3D automatically and makes it fully user-controlled

float Actor3D::GetAnimationStartTime(index/name);
float Actor3D::GetAnimationEndTime(index/name);
float Actor3D::Get/Set(Current)AnimationPosition(index/name);

Actor can be divided internally into several parts animation and skeleton;

Let me explain:
It's good sometims to make an object, that can be set to a specific animation frame (what about valve-controlled or rusty door?).
Actor3D doesn't provide this functionality, and I think it is needed.
There can be two function sets for animations:
1) Controlling animation player (i.e. Get start/end time, current animation name/index, total number of animations, etc.)
The actor 3D can be treated like an "animation player" i.e. - it cannot walk automatically, but I can set explictly animation frame, animation speed, animation set, that are playing right now. (IMHO)This functionality is needed.
2) (optional) To make various IK possible It would be great to have an access to character bones/skeleton. This can be done by exposing transform (at least, for a plugins) matrices through bone names/indexes. The IK is a rich subject, I don't think it is needed right now, just to
give an idea...

7) Request: actor/model/scene loader plugin.

WME needs to be accessible for a large demographics of users, using various 3D packages. Hence the use of commonly supported formats.

that's your choice. I just have an another opinion.

Request: hardware acceleration support.

Um, I'm afraid pure device is a no-go for lil' old WME.

Why? It is quite easy! You can check DeviceCaps at startup. I'm talking just about D3DDEVCAPS_HARDWARE_VERTEXPROCESSING, nothing more. It's quite simple to switch this on and off, it will not take much time to implement. At least an option for an user to enable hardware vertex processing would be great.

9) Request: stencil shadows optimizations

But even if the extrusion is done in shaders, there's still a great deal of work that needs to be done in CPU, isn't there? Like.. preparing the model used for the extrusion?

Yes. Model is prepared. And there are some restrictons. But (IMHO) I suppose that having a little lag an startup, or to have certain model for shadows with is better, than having game run slow without thous restrictions... (no offence)

Well... even if you don't like that idea... how do you render stencil shadows right now? I suppose I could provide several optimizations for dynamic geometry rendering (because it's really slow right now). What about dynamic VertexBuffers? They provide a good speedup. I've wrote a *.cpp recently (about a month ago) that provide a GL-style rendering in DirectX. It's not completed, but maybe it can make your code faster?

10) Request: Mesh/3DEntity/static Mesh class.

I disagree. You can't just throw in a plain ID3DXMesh (or something like that). It needs to be wrapped into some game object. And why not Actor3D, since it already provides all the necessary functionality? Some "Entity3D" would be internally just Actor3D with a few scripting methods cut off.

Well. I don't need an ID3DXMesh, since I completely dislike some of D3DX extensions. I"m talking about a static object like a lamp, with another kinds of controls. For  example - is it possible right now to change "up" direction of an actor? To make it walk on the wall, for example? I'm just talking about some meshes to be used for items and attachments. About objects, that can be placed anywhere in space and oriented in any way, without interfering current scene.
There are many good things that can be implemented with that kind of object even with all current restrictions.

More comments?

[Mnemonic]

More comments?

Just a few

And if it is a struct, what names are used for the fields? uppercase or lowercase?
And there is no mention in documentation about what type is used for color.

It's not a stuct. I said it was a 32bit RGBA value. 0xAARRGGBB.

Also the color is an int (in WME). As you may already know, the size of an int isn't defined anywhere as standart. So it may be 16 bit, it may be 32 bit, and it may be even 64 in some cases. And it can be long and short. So, the question is how big is your "int"? Looking through the code I found that it is, most likely, a DWORD. So it must be 4bytes long. Using of and "int" is quite confusing, believe me.

WME is 32bit application. The int is 32 bits large.

Well what about conversion routines for a certain type?

The IWmeValue tries to convert from any type to any other type (of course without some obvious impossible combinations, like converting anything into native WME object). Converting from string to int should work too, I don't know why did you get access violation.

I've implemented this already, it's easy.

Well it gets a little less easy when dealing with saving/restoring object references and such, but, yeah, it should be possible.

I'm talking just about D3DDEVCAPS_HARDWARE_VERTEXPROCESSING, nothing more.

You were talking about pure device before...

[ErV]

And if it is a struct, what names are used for the fields? uppercase or lowercase?
And there is no mention in documentation about what type is used for color.

It's not a stuct. I said it was a 32bit RGBA value. 0xAARRGGBB.

I know, I just wanted to explain that it isn't easy to guess since it is undocumented in help file.

Also the color is an int (in WME). As you may already know, the size of an int isn't defined anywhere as standart. So it may be 16 bit, it may be 32 bit, and it may be even 64 in some cases. And it can be long and short. So, the question is how big is your "int"? Looking through the code I found that it is, most likely, a DWORD. So it must be 4bytes long. Using of and "int" is quite confusing, believe me.

WME is 32bit application. The int is 32 bits large.

There is no such guarantee for another compiler. (non Microsoft)
Using DWORD could be less confusing.

Well what about conversion routines for a certain type?

The IWmeValue tries to convert from any type to any other type (of course without some obvious impossible combinations, like converting anything into native WME object). Converting from string to int should work too, I don't know why did you get access violation.

This piece of code doesn't exists anymore. So the error can't be recreated.

I'm talking just about D3DDEVCAPS_HARDWARE_VERTEXPROCESSING, nothing more.

You were talking about pure device before...

Unless you are using IDirect3DDevice9->GetXXX calss very often there is no big difference.
I just do not understand what is the problem with PURE_DEVICE and WME?

[Rave-n]

actor.AttachScript("scripts\shadow_daemon.script"); //actor is an actor3d

//ShadowManager is my class implemented in plugin
global shadowManager = new ShadowManager();

----------
while (true){
    var numLights = shadowManager.GetNumLights();
    var LightPos;
    var noLightFound = true;
    var diff;
    var distance;

    for (var i = 0; i < numLights; i = i + 1){
        Light currentLight = shadowManager.GetLight(i);
        diff.X = currentLight.PosX - this.PosX;
        diff.Y = currentLight.PosY - this.PosY;
        diff.Z = currentLight.PosZ - this.PosZ;
        var curDistance = Math.Sqrtf(diff.X*diff.X + diff.Y*diff.Y + diff.Z*diff.Z);
        if ((noLightFound)or ((curDistance < distance)and (distance < currentLight.outerRadius))){
            distance = curDistance;
            LightPos = diff;
            noLightFound = false;
        }
    }
    actor.SetLightPosition(LightPos.X, LightPos.Y, LightPos.Z);
    sleep(20);
}

In the latest beta it is possible to use Scene.GetLightName but all it seems to return is the name of the object and no relavent data for it. Am I just being stupid or is this info still not available to the scipts?