Heya - is there any problems with re-instancing a d3d mesh object on the fly?
I wish to release and then re-instance one or more meshes during Rending.
How would one go about this? I tried halting Rending, its not enough.

Any Ideas?
Posted on 2002-08-28 00:53:25 by Homer
Afternoon, EvilHomer2k.

Once a mesh is released, it's gone/deleted/bye-bye.
So you're not actually re-instancing a mesh. You're recreating one.

As for halting rendering....
why?
Your proggy should be drawing and rendering as fast as it possibly can. Anything dynamic/animated should be taking into account whatever time has elapsed.

Your Topic says Dynamic Scenes. So you're wanting to modify the scenery on-the-fly? Or is it something else?

There are many ways to have dynamic objects. Have you had a look at the DolphVS sample of Microsofts? It uses three meshes, and just blends between then. Skinned Meshes use one mesh, and moves/rotates groups of vertices.

Or are you talking about blowing holes in walls?

Cheers,
Scronty
Posted on 2002-08-28 02:29:22 by Scronty
Basically, I wish to re-use my mesh object pointers
(I don't plan on making heavy use of this but sometimes its necessary)

Your Dolphins example is a good one, but it loads several static mesh objects and tweens them as you mentioned: let's say when the user presses some button or key, I wish to throw away the dolphin mesh and replace it with some other mesh, or if I wished to change the text content of a window displaying 3d rendered text.. imagine that we can't for some reason have the mesh all ready to go when Rending begins, maybe a Player joined a game, and wishes to use a custom player mesh that everyone else can see...
Posted on 2002-08-28 02:58:24 by Homer
Afternoon, EvilHomer2k.

Okay.
Then you release the previous mesh, and set the pointer to it to null first.
Make sure during rendering that you're checking the pointer for null before attempting to render it ;) .

Now to create the replacement mesh....
Depending on your target system, you may have a problem with the creation of a new mesh during gametime.

I haven't tested just how long it takes to load in and prepare a mesh, since I've only ever done it *before* the rendering pump begins.

You could use an in-game "Pause" while the new mesh is being created.

Instead of using D3DXLoadMeshFromX to load a mesh from a file, you could use D3DXLoadMeshFromXInMemory, however that's only useful if it's ok for you to have the mesh preloaded into memory.

Cheers,
Scronty
Posted on 2002-08-28 07:04:08 by Scronty
Hmmz I can't seem to be able to switch a meshobject during runtime :(
I've tried, I crash everytime.
I modified your font mesh example for this, so that it checks for pre-existing lpMesh, killing it and replacing it.
I use a flag to prevent Rending while InitGeometry is being called.
Surely I don't have to Reset the device or something do I??
These are the hairy questions which need to be asked...
(I hate the m$ concept of a quiver of arrows that magically return when destroyed)
Posted on 2002-08-28 08:47:08 by Homer
Afternoon, EvilHomer2k.

Attached is the 3D Font proggy, modified so that it releases and recreates a mesh every 5 seconds.

Just a subtle, subtle (really subtle) hint here.....
Could you attach what you've done, so that I can see where the bug is?:grin:

Cheers,
Scronty
Posted on 2002-08-29 03:58:52 by Scronty
ok very BASICALLY what I did is this:
I added the code to release lpMesh just before we create it within InitGeom, allowing me to be able to call InitGeom again...
.
.
.
.if lpMesh != NULL
mcall ,IUnknown_Release
xor eax,eax
mov lpMesh,eax
.endif

mcall ,ID3DXMesh_CloneMeshFVF, D3DXMESH_MANAGED, \
D3DFVF_CUSTOMVERTEX, lpd3dDevice, ADDR lpMesh
mov hr, eax ; Save the result
.if hr != D3D_OK
ret
.endif
.
.
.

...and changed the address of the string it uses to create the text, so that I could call InitGeom again later..
then I added a Flag which gets monitored within WinMain's Message loop.
We set the flag before calling InitGeom, and reset it when we return.
This flag is used to prevent Rendering of lpMesh during (re)initialization.
Posted on 2002-08-29 12:11:18 by Homer
hmm ok I just tried ur binary, it crashed at offset 143c.
So I compiled it myself, and ran it again.
Now it crashed at 1439.
I didn't look in my debugger what the drama there was,
though I find the 3 byte difference notable in itself.
This is basically what happened when I tried what looks to be basically the same thing, except I didn't do it within the Render proc.
This is kinda kinky huh, maybe my rusty old ati rage2's sexy detonator drivers aren't all that hot? Or maybe its that the rage chipset is on the motherboard and is a variant of the card-based chipset of the same name?
Maybe m$ didn't hand ati the correct specifications for dx8 during development?
The error code was a lousy c000005 u know, bad memory access violation
...it ran ok on ur gear?
Posted on 2002-08-29 12:30:31 by Homer
Afternoon, EvilHomer2k.

hmmm.


mcall [mesh],ID3DXMesh_CloneMeshFVF, D3DXMESH_MANAGED, \
D3DFVF_CUSTOMVERTEX, lpd3dDevice, ADDR lpMesh
mov hr, eax ; Save the result
.if hr != D3D_OK
ret
.endif

^^^where is that code? Inside InitGemetry?
For that to work, "mesh" has to be a valid mesh.
It's not recreating a mesh. It's cloning one.
So unless you're actually generating the various meshes at the start of your proggy, and just copying them into the pointer you're using for rendering, it won't work.

And if you *are* generating the various meshes at the start of the proggy, then it'd be better to just copy the appropriate meshes pointer to the pointer you're using in rendering.
____________________________

I had a look where that crash is occuring. Seems to be in the middle of the ...
;   Turn on the zbuffer

mcall [g_pd3dDevice],IDirect3DDevice8_SetRenderState, D3DRS_ZENABLE, TRUE

call.
00401430    |> 6A 01             PUSH 1

00401432 |. 6A 07 PUSH 7
00401434 |. 8BD2 MOV EDX,EDX
00401436 |. A1 7F304300 MOV EAX,DWORD PTR DS:[43307F]
0040143B |. 50 PUSH EAX
0040143C |. 8B00 MOV EAX,DWORD PTR DS:[EAX]
0040143E |. FF90 C8000000 CALL DWORD PTR DS:[EAX+C8]

weird. This shouldn't be happening. How is it crashing on a "mov edx, edx" (and where did that mov edx, edx come from, anyway?!?)

You've got DX8.1 installed, right?
This runs fine on Celery700 SiS630(chip on mainboard) 16MB shared.
____________________________

I originally thought it may be because of the selected font (Courier New) as common font-types vary between some OSes.

Cheers,
Scronty
Posted on 2002-08-29 18:37:05 by Scronty
Yep, have 8.1 installed as a component of XP.
Yep, I was doing that within InitGeom.
just took a look whats happening at 401439...


push 1
push 7
mov edx,edx
mov edx,dword ptr[43307f]
push eax
** mov eax, dword ptr ** <--- crash line
call dword ptr
call 401767
mov eax,0
leave
ret4

value in eax at point of crash is zero. (esi/edi are also zero)
ok so I guess we are trying to apply a null object.
What the heck is happening?
Posted on 2002-08-29 23:39:49 by Homer
Afternoon, EvilHomer2k.

Well....
That kinda answers it.

Seems pd3dDevice is NULL, but the CreateDevice call is succeeding?

Maybe the attached proggy will work?

Same as before, however now it will try to put the display res into 800x600x32->24->16 bit mode.

Cheers,
Scronty
Posted on 2002-08-30 01:53:48 by Scronty
I will try your sample in a moment,
I got your previous one working.
What I did is simply switch it back to Windowed mode.
Seems my card didn't like starting in fullscreen using the current desktop resolution... wtf? lol
Anyhow, here's the linkedlist server/client with rejuvenating single meshobject.
You can chat in 3D !!
Keep the chat lines down to a reasonable length,
make sure you choose different usernames,
and away you go.

Only Clients can chat in this example,
if you select a listed user, you can whisper a pm to them only.

I know it isn't strictly game-related, however I think you would agree that this example covers common ground for would-be DX gamecoders..

(you'll need to add the dx dll's - filesize limit here is tiny)
Posted on 2002-08-31 04:48:26 by Homer
ok just tried that smaple u posted..
fullscreen white , no crash but then no rending either.
Nice huh.
Anyhoo, problems like this are all good.
I mean, we do want our stuff to run on anything out there, don't we?:)
Sooo anyways... my card seems peculiarly picky about fullscreen modes...
Posted on 2002-08-31 04:56:43 by Homer
Afternoon, EvilHomer2k.

Problem with the proggy.

The large static control is left greyed. No 3D text appears :( .

Two questions:
1) do you ever check your PM?
2) ever go to the IRC #win32asm channel on ethernet?

Cheers,
Scronty
Posted on 2002-08-31 06:14:22 by Scronty
Afternoon, EvilHomer2k.

Got the text to display. I've attached the adjusted proggy.

Cheers,
Scronty
Posted on 2002-08-31 07:30:52 by Scronty
Heya.
Weird - my reply disappeared which I posted yesterday.
I've replied ur PM.

Attached is the Donuts3D code, a work in progress.
It's full of bugs, I repeat my earlier statement that I wasn't actually planning on rebuilding Donuts3D as it stood but simply wanted to poke around inside to investigate m$'s preferred order of operations etc.
It was during the transliteration (I won't use the word translation) of this source that I decided C coders have it too good with their ability to instance objects whenever they like. It was that which led to the LinkedObject code, as I discovered that modern coders just don't use static arrays much, and that modern coders don't even know what a lookup table is anymore.
(huh? vtable? lol)

Feel free to host that Donuts stuff and mess with it if u like, but personally I think that project is a time-waster, infact I only did it to save time down the track, to avoid implementing an unworkable or unwieldy driving logic.
Posted on 2002-08-31 20:22:01 by Homer