Please login or register.

Login with username, password and session length
Advanced search  

News:

Latest WME version: WME 1.9.1 (January 1st, 2010) - download

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - ErV

Pages: [1] 2 3 4
1
Feature requests, suggestions / Re: Several suggestions...
« on: October 26, 2006, 09:32:42 PM »
Quote
Quote
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.

Quote
Quote
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.

Quote
Quote
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.

Quote
Quote
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?

2
Feature requests, suggestions / Re: About WME for Linux again
« on: October 25, 2006, 11:57:38 PM »
Well, the application I was talking about was called WineX.

WineX is the old name of the Cedega  ;) ;D
Well... thanks for the info.
I guess too much time passed since I've first tried to use RedHat Linux 9 until now, when I've desided to switch from WinXP to ASP 11... :)

3
Feature requests, suggestions / Re: Several suggestions...
« on: October 25, 2006, 11:47:37 PM »
Ok, some comments...

Quote
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.

Quote
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.

Quote
Quote
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.

Quote
Quote
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.

Quote
Quote
5) Request: LowLevel scene access. (Lights, geometry)
Should be possible.
I've implemented this already, it's easy.

Quote
Quote
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...

Quote
Quote
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.

Quote
Quote
8) 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.

Quote
Quote
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?

Quote
Quote
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? :)

4
Feature requests, suggestions / Re: About WME for Linux again
« on: October 25, 2006, 02:41:55 PM »
I've heard about a commercial version of Wine that can add (some) DirectX support for emulated applications in Linux. Never had it, though.

That is Cedega by Transgaming. http://www.transgaming.com
Well, the application I was talking about was called WineX.

5
Feature requests, suggestions / Re: About WME for Linux again
« on: October 24, 2006, 11:43:40 PM »
I think that WME interpreter under Linux for running games would be enough. The tools work in Wine.
I've heard about a commercial version of Wine that can add (some) DirectX support for emulated applications in Linux. Never had it, though.

6
Feature requests, suggestions / Several suggestions...
« on: October 24, 2006, 11:39:59 PM »
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.

8) 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?

7
Technical forum / Re: ZWriteEnable == false for an actor3d
« on: October 22, 2006, 09:37:15 PM »
I know what you mean, but you asked if it broke the scene. If the render state is set just before the model is rendered (and after the shadow is rendered), it should only affect the model. That said, there's no property for doing so, it would need to be added.

You know, the problem is WME is pretty high-level game engine, which actually tries to shield the users from low level stuff like render states etc. Admitably, this makes some advanced 3D effects hard or impossible to do, but there's always some trade off.
Thanks for an answer :(. Just wanted to make sure there is no way to implement this thing right now.

P.S. (IMHO)I think that having a low-level API for WME layer would be great...

8
Technical forum / Re: ZWriteEnable == false for an actor3d
« on: October 21, 2006, 02:39:56 PM »
I don't know. Probably. The 2D scene itself is not using z-buffer.
I mean - I need to disable this state just for single actor. Not for the whole scene.
(Disabling it through IDirect3DDevice8 doesnt work anyway (because of stencil shadows))

9
Technical forum / ZWriteEnable == false for an actor3d
« on: October 20, 2006, 08:08:14 PM »
Hello.
I need to disable Writing to a ZBuffer for a specific actor. (IDirect3DDevice8->SetRenderState(D3DRS_ZWRITEENABLE, FALSE))
Is there any way to do this just for a single actor, without breaking all scene?

10
Technical forum / Re: Problems with flat shadows.
« on: October 20, 2006, 08:01:39 PM »
Ok, try this: http://dead-code.org/download/wme_latest.zip

I removed the infinite clamping, increased the far clipping for shadow projection and fixed the disabled light loading from 3ds.
You mean - zFar/zNear for shadow renderer is static? And, maybe FOV, too? Wouldn't be better to change zFar, zNear and FOV for rendering shadows dynamically, based on character bounding box/distance from light? (Calculations are quite easy) It would solve model clipping problem. What do you think?

11
Technical forum / Re: Problems with flat shadows.
« on: October 20, 2006, 11:24:36 AM »
P.S. Why don't you use D3DPRESENTINTERVAL_IMMEDIATE? It would be a big speedup for a game. (what about 200 fps on Riva TNT?)
IMO that's not something a game should force the player into. At least it should be user-selectable.
That's your choice.

But what can I do with disappearing shadows?

12
Technical forum / Re: WME hangs on 3ds files!
« on: October 20, 2006, 11:23:38 AM »
I can send file, causing problems, if requested.
That would be helpful, thank you. I believe the chunk isn't supposed to be empty, it should contain one boolean value specifying whether the light is on/off.
I've sent the file.

13
Technical forum / Re: SpotLight ranges are not working?
« on: October 20, 2006, 11:13:39 AM »
Unfortunately the 3DS file doesn't contain the attenuation info (correct me if I'm wrong).
Unfortunately, you are wrong.

Lights in 3dsmax has additional parameter - "Far Attenuation". If enabled, this parameter produces two additional subchunks in chunk 0x4600. Those chunks contains "far attenuation inner radius" and "far attenuation outer radius".
The chunks are:
0x465A (outer radius - 4bytes float)
0x4659 (inner radius - 4bytes float)

both chunks contains just a single float, so each is  10 bytes long.

The object will be lit at maximum brightness (original color * 1.0f), if distance <= innerRadius,
and it will not be affected by light at all, if distance >= outerRadius;
So, in 3dsmax attenuation (linear) is calculated this way:
float attenuation =
 (distance >= outerRadius)? 0.0f:
  (distance <= innerRadius)? 1.0f:
   (distance - innerRadius)/(outerRadius - innerRadius);

While it is not possible to implement this attenuation model without writing a vertex shader,
it'll be good to make an approximation at least. For example - you could ignore innerRadius value and make light fade out at outerRadius;

This can be achieved by setting, for example D3DLIGHT8::Attenuation1 to some radius-dependant value.
What value is to be assigned, can be guessed during expirementation, since DirectX attenuation model isn't quite good...

It would be a great thing to do, since the lack of attenuation combined with limited lightRange and vertex lighting produces a quite ugly graphical effect.

There is also additional chunk that controls light's "multiplier" value:
0x465B
As I presume/suppose, light color is supposed to be multiplied by this value to make light look the way it was in 3dsmax.

There are also decay parameter, I think, but I was unable to make my 3dsmax export something unusual except those 3 chunks.

P.S. With the light having attenuation, there will be unlit spots in scene. And they will be black. That's why I asked about global ambient lighting.

14
Technical forum / Re: Controlling Actor3D transparency.
« on: October 20, 2006, 10:57:45 AM »
Wouldn't a semi-transparent texture with an alpha channel be enough for your cause?
No, becuase transparency should be controlled by script.

15
Technical forum / WME hangs on 3ds files!
« on: October 19, 2006, 10:08:15 PM »
Hello.
I've got a problem. Wme hangs on 3ds files, that contain
"Light" chunks(0x4600) with "DL_OFF" (maxsdk\samples\impexp\ofile.h) subchunk (signature 0x4620).
This chunks is 6 bytes long, conains no data and means only that the light is switched off. 3dsmax 6 exports this chunk, when scene contains a light that has "On" checkbox deselected.

I can send file, causing problems, if requested.

Thanks.

Pages: [1] 2 3 4

Page created in 0.425 seconds with 23 queries.