Sorry your browser is not supported!

You are using an outdated browser that does not support modern web technologies, in order to use this site please update to a new browser.

Browsers supported include Chrome, FireFox, Safari, Opera, Internet Explorer 10+ or Microsoft Edge.

DarkBASIC Professional Discussion / Is it possible to edit vertex faster?

Author
Message
Kuper
18
Years of Service
User Offline
Joined: 25th Feb 2008
Playing: Planescape:Torment
Posted: 7th Dec 2011 09:50
Hi!
So we have DBPro command "set vertex data position" and similiar command is in DKShop plugin. Anybody knows any ways to edit vertex data even faster? Maybe Dll or something else?
chafari
Valued Member
20
Years of Service
User Offline
Joined: 2nd May 2006
Location: Canary Islands
Posted: 7th Dec 2011 11:11
Quote: "Anybody knows any ways to edit vertex data even faster?"


Are you going to animate mesh or are you going to model mesh ?

Cheers.

I'm not a grumpy grandpa
Kuper
18
Years of Service
User Offline
Joined: 25th Feb 2008
Playing: Planescape:Torment
Posted: 7th Dec 2011 12:30
just move the object by moving its vertexes.
chafari
Valued Member
20
Years of Service
User Offline
Joined: 2nd May 2006
Location: Canary Islands
Posted: 7th Dec 2011 12:41 Edited at: 7th Dec 2011 12:44
Quote: "just move the object by moving its vertexes"


Can you be more specific?. With vertexdata you can do much more than move object

http://forum.thegamecreators.com/?m=forum_view&t=181531&b=1

Cheers.

I'm not a grumpy grandpa
Kuper
18
Years of Service
User Offline
Joined: 25th Feb 2008
Playing: Planescape:Torment
Posted: 7th Dec 2011 13:28
i attach objects to one by add to vertex data command.After that if i need to move one of attached objects i used set vertex data position.
Dbro dont like many objects in screen espesially with deferred shading.
IanM
Retired Moderator
23
Years of Service
User Offline
Joined: 11th Sep 2002
Location: In my moon base
Posted: 7th Dec 2011 14:16
Experiment with the LOCK VERTEXDATA FOR LIMB command - that last 'Lock Mode' parameter can make a big difference to the speed of your vertexdata commands.

Green Gandalf
VIP Member
21
Years of Service
User Offline
Joined: 3rd Jan 2005
Playing: Malevolence:Sword of Ahkranox, Skyrim, Civ6.
Posted: 7th Dec 2011 15:44
Interesting. Could you be more specific? I've never really understood the significance of those lock modes.
IanM
Retired Moderator
23
Years of Service
User Offline
Joined: 11th Sep 2002
Location: In my moon base
Posted: 8th Dec 2011 14:57
The lock mode determines the post-processing that will take place when you unlock the mesh.

Lock mode 0 causes all buffers for affected objects to be replaced completely during the SYNC process.
Lock mode 1 causes the existing vertex buffer daa to be refreshed from the modified data when you unlock the mesh.
Lock mode 2 is the same as lock mode 1, except it also copies the modified data over the original loaded data so that the modifications can be saved - it's slightly slower than lock 1 during unlock for that reason.

Bit of background to help that make sense:
Each object has 3 copies of the vertex data when you start.
1. The original loaded data
2. The modified data
3. The vertex buffer

When you are modifying the data, you are modifying the 2nd version. When you unlock from mode 2, the 2nd version is copied over the 1st. In all cases, the 3rd version is also updated from the 2nd, but as it's a vertex buffer and hence a Direct3D structure, that data can be lost and need to be rebuilt.

Green Gandalf
VIP Member
21
Years of Service
User Offline
Joined: 3rd Jan 2005
Playing: Malevolence:Sword of Ahkranox, Skyrim, Civ6.
Posted: 8th Dec 2011 19:17
Thanks. Which of these copies is used if you:

(a) use



or

(b) use



?
chafari
Valued Member
20
Years of Service
User Offline
Joined: 2nd May 2006
Location: Canary Islands
Posted: 8th Dec 2011 19:26
Quote: "Which of these copies is used if you"


I use both in my Lathe Tool example. We can edit the mesh and save again to dbo from other code.

Cheers.

I'm not a grumpy grandpa
IanM
Retired Moderator
23
Years of Service
User Offline
Joined: 11th Sep 2002
Location: In my moon base
Posted: 8th Dec 2011 21:38
@GG,
Save object uses copy 1.
Make mesh from object uses copy 2.

Green Gandalf
VIP Member
21
Years of Service
User Offline
Joined: 3rd Jan 2005
Playing: Malevolence:Sword of Ahkranox, Skyrim, Civ6.
Posted: 8th Dec 2011 21:43 Edited at: 9th Dec 2011 03:02
Thanks, I'll try to remember that.

[Edit: Added missing word. I'll try to remember that as well in future. ]
david w
20
Years of Service
User Offline
Joined: 18th Dec 2005
Location: U.S.A. Michigan
Posted: 9th Dec 2011 22:02
I don't know the internal workings of DBP, but I have assumed that the lock modes are a direct wrap of the DX command D3DXMESH myMesh->LockVertexBuffer( mode, ptr);

Something like this:

unsigned char *pVertices = NULL;
OriginalMesh->LockVertexBuffer( D3DLOCK_READONLY, (LPVOID*)&pVertices);

Here is the M$ link:

http://msdn.microsoft.com/query/dev10.query?appId=Dev10IDEF1&l=EN-US&k=k(LOCKVERTEXBUFFER);k(DevLang-%22C%2B%2B%22)&rd=true

And I thought the save mesh command was probably wrapped around this command:

D3DXSaveMeshToX(meshFname,
pMeshData->pMesh,
NULL,
Mesh->meshMaterials,
NULL,
Mesh->NumMaterials,
D3DXF_FILEFORMAT_TEXT
);

But then like I said I don't really know the internal workings, I guess since they are taking it straight from the memblock data then that explains why if you load a .X file up and then convert it to a mesh, you loose all UV data and more.
IanM
Retired Moderator
23
Years of Service
User Offline
Joined: 11th Sep 2002
Location: In my moon base
Posted: 9th Dec 2011 22:17
Nope, nothing to do with the DirectX lock modes - what we're talking about is all internal to DBPro, although DBPro does lock the vertex buffer to refresh the mesh data from the user-amended engine data.

david w
20
Years of Service
User Offline
Joined: 18th Dec 2005
Location: U.S.A. Michigan
Posted: 9th Dec 2011 22:41
Thats good information to know. It seems you know alot about how DBP works internally. I have always wondered about one thing however and this has nothing to do with lock modes but rather how dbp passes data into shaders maybe you can anwser this for me because its been a totaly mystery to me.

In direct X you would pass in a matrix either through its handle or its name. Such as myEffect->SetMatrix( "WVP", &WVP), this is the only way that I know of to set these. However in DBP it seems that people just declare Matrixes however they wish and don't have to worry about setting them. I am wondering how this is done. Additionally it seems that DBP also sets the input structure in a similar fashion. Up until this point it seems to be a totaly mystery to me, because and I know there is a way to read the vertexdata structure for the shader but I just can't figure out how DBP is doing it. Any insights would be welcome.

Thank you.
Green Gandalf
VIP Member
21
Years of Service
User Offline
Joined: 3rd Jan 2005
Playing: Malevolence:Sword of Ahkranox, Skyrim, Civ6.
Posted: 10th Dec 2011 01:19
Yes, I'd like to know how it's done too.

To keep things focussed on a concrete example, let's consider a standard matrix. Most shaders use the WorldViewProjection matrix and, as david w says, we can call that anything we like in our shader code, davidwWVP perhaps. All I know is that DBPro (or a function it calls) uses the semantic part of the shader declaration to recognise that the object's world view projection matrix is the one intended. So our shader code might have the line:



so I guess david w's question is this "How does DBPro know that the matrix davidwWVP needs to be filled with an object's world view projection matrix?".
TheComet
18
Years of Service
User Offline
Joined: 18th Oct 2007
Location: I`m under ur bridge eating ur goatz.
Posted: 10th Dec 2011 03:06
This probably isn't very helpful, but here is some content from one of the help files in DBP on shaders:



TheComet

david w
20
Years of Service
User Offline
Joined: 18th Dec 2005
Location: U.S.A. Michigan
Posted: 10th Dec 2011 04:33
Yes GG that is exactly what I mean, and I really would like to know how it is done, because I have tried to simulate this myself but I can't really see a way around how it just knows to set it with the right combination of matrix calculations.

I think I can see how they are doing the vertex declaration input struct, however in effect it does not seem they are even applying a vertex declation because of the use of FVF formats.
Green Gandalf
VIP Member
21
Years of Service
User Offline
Joined: 3rd Jan 2005
Playing: Malevolence:Sword of Ahkranox, Skyrim, Civ6.
Posted: 10th Dec 2011 12:50
david w

I'm as baffled as you are. The DirectX SDK seems to imply that you could use something called SasBindAddress to detect these things. If you have the SDK do a search for sas and you should see the entry Data Binding (see attached screenshot). Study that entry carefully. It suggests to me that variables declared with that annotation, such as the following from "reflect.fx" in the EffectParam sample,



can be easily matched to their correct values somehow. But I confess I can't see where the Sas idea is actually being used.

I'm not a C++ programmer but I think a particularly relevant DX9 sample is that EffectParam one. If you look at the C++ code in EffectParam.cpp you'll find the following section about three quarters down the file:



It's not obvious to me how the SasBindAddress concept is being used - unless it's buried in things like *g_Camera.GetViewMatrix(). Such things will probably make more sense to you so I'll leave it to you to explore.

Hope this helps. With luck IanM will fly in and put us out of our misery.
enderleit
19
Years of Service
User Offline
Joined: 30th May 2007
Location: Denmark
Posted: 10th Dec 2011 14:24
I'm no shader-expert, so this might not be true, but I figured that the semantic was the one that told the shader what matrix it is.



Here the semantic(second part) is a "variable" passed in by DBPRO that contains the WVP matrix, and we simply tell the shader that we want to reference that "variable" using the name "davidwWVP".

I might be wrong though.

Green Gandalf
VIP Member
21
Years of Service
User Offline
Joined: 3rd Jan 2005
Playing: Malevolence:Sword of Ahkranox, Skyrim, Civ6.
Posted: 10th Dec 2011 14:47 Edited at: 10th Dec 2011 14:48
You're right of course, but the point is: at what stage is that information used or set?

The shader is just a bit of code - it has to be processed at some point and in DirectX/C++ my understanding is that it will be loaded using something like



(from the EffectParam.cpp code mentioned earlier). That code is then followed in the example by lines setting various things via something called a parameter block. What I can't see - and neither can david w (who is a C++ programmer unlike me ) - is where precisely is the semantic information used?

Edited punctuation.
david w
20
Years of Service
User Offline
Joined: 18th Dec 2005
Location: U.S.A. Michigan
Posted: 10th Dec 2011 18:18
@enderleit - I can see why you would think the second part would be the handle that DBP would reference, but that handle can and does get named many different things, such as worldVP or WVP. So in effect even it it was that neat and easy I would not have bothered posting about this. Its not like it really affects me or anyone else, but rather it is more of a curiousity about how it is done. In C++ you have the shader just as you do in DBP and you can read the shader so you know what to set manually anyways.

@GG - While your SDK example is relevant it also fails to identify what is really going on. A handle is only a reference to the string name of the matrix in the shader. You still have to know the string name to be able to set the reference to the string name and in addition you have to know what information to pass into that matrix. For example WorldInvTranspose would be need to be set properly to be of any practical value to the shader, regardless of if you use the string name or the reference to the string name.

In the other part of your example they are merely setting the values that have been pre-computed in some class/struct and just passing those values to the handle or sting name.

Looks like this is probably going to remain a mystery.
Green Gandalf
VIP Member
21
Years of Service
User Offline
Joined: 3rd Jan 2005
Playing: Malevolence:Sword of Ahkranox, Skyrim, Civ6.
Posted: 10th Dec 2011 18:57 Edited at: 10th Dec 2011 18:58
Quote: "I can see why you would think the second part would be the handle that DBP would reference,"


It is precisely that - it only works if you use a semantic from a certain list of accepted semantics. There is no other way that DBPro can know which matrix to fill (other than those you specify manually using set effect constant matrix). You can name the variable itself anything you like. What isn't clear is how DBPro (or something DBPro uses ) recognises the semantic.

Quote: "While your SDK example is relevant it also fails to identify what is really going on."


But that example includes the string names (of the shader constants, not their semantic descriptor) as in the following snippet:



What I can't see is the relevance of the Sas string in all this.

I also can't see in that C++ code (or the associated helper files) where g_Camera.GetViewMatrix() actually gets its value filled in.
david w
20
Years of Service
User Offline
Joined: 18th Dec 2005
Location: U.S.A. Michigan
Posted: 10th Dec 2011 20:11
Most likely it is something like this. There is a g_Camera class that controls the "camera" which is in reality only a view matrix. For example:



Then this will simply build a view matrix that can be passed to the shader with the command in the sample:

V( g_pEffect->SetMatrix( "g_mView", g_Camera.GetViewMatrix() ) );

So you see you sill have to know the view matrix that was constructed by the g_Camera class.

Basically before you pass a matrix in you must build it first, then pass it by name or reference. In DBP you never need to build, name, or let alone pass them to the shader. However in DBP for the shaders to work they do need the matrix's, its a mystery to me.
Green Gandalf
VIP Member
21
Years of Service
User Offline
Joined: 3rd Jan 2005
Playing: Malevolence:Sword of Ahkranox, Skyrim, Civ6.
Posted: 10th Dec 2011 20:53
Quote: "So you see you sill have to know the view matrix that was constructed by the g_Camera class."


Yes, that was my understanding of the class definition in the helper file.

Quote: "However in DBP for the shaders to work they do need the matrix's, its a mystery to me."


Not quite. You can calculate them manually in DBPro if you wish. One thing is clear - DBPro somehow uses the semantic to tell it that it needs to fill in the relevant variable with it's values. I believe something similar is supposed to happen in the DX9 C++ samples - but I can't see where precisely. After all, what is the point of having a declaration labelled with a semantic if the application uses the variable's actual name (as in the last snippet I posted)?

It's quite possible of course that the particular DX9 sample we've been discussing isn't using the semantic/sas labelling even though the semantics are given in the fx files used. There's only one way to find out.

Where's IanM when you need him? I expect he's having fun watching us squirm on this particular hook.

Anyway, why do you need to know how DBPro does it? Any reason why you can't compute them manually in your code? In fact, are they computed manually in that EffectParam sample I referred to?
david w
20
Years of Service
User Offline
Joined: 18th Dec 2005
Location: U.S.A. Michigan
Posted: 10th Dec 2011 21:01
I suppose don't really need to know but it was more of me just being curious of how DBP does it. In every sample I have ever seen they either set they effect matrix's by string name or by reference and again you need the string name to set the reference.

Yes in the EffectParam sample they are computed manually. I don't know I just set my effects by string name and everything works out fine for me. It like I said I have been curious about this for some time now because I prototype my projects in DBP and then convert that to Direct X native and I have always wondered how it is done.
Green Gandalf
VIP Member
21
Years of Service
User Offline
Joined: 3rd Jan 2005
Playing: Malevolence:Sword of Ahkranox, Skyrim, Civ6.
Posted: 10th Dec 2011 21:53
Quote: "I have always wondered how it is done."


Me too. And the DX9 docs and samples just add to the confusion. I'll try to consult The Oracle and report back if I get anything useful.
IanM
Retired Moderator
23
Years of Service
User Offline
Joined: 11th Sep 2002
Location: In my moon base
Posted: 11th Dec 2011 15:46 Edited at: 12th Dec 2011 14:37
Quote: "Where's IanM when you need him?"

Not watching you squirm. I was having a day out with my Brother and a few friends as he's moving away in the new year - it's the last chance we'll have to all get together for a while.

Anyway, the answer is 'it's the semantic'. DBPro uses that to determine what information/updates need to be provided to that variable in the shader.

When the shader is loaded, it is analysed to determine which semantics are required (using a fixed list within DBPro). When one is detected, it is linked to the matching global storage for that item (I think it's global, but I haven't chased through all the code yet). Then when you render the object, the globals are updated.

The relevant routines can be found in DBOFormat.cpp and are:
- cSpecialEffect:b][/b]ParseEffect - parse the semantics
- cSpecialEffect::AssignValueHookCore - link the semantic value to storage
- cSpecialEffect::ApplyEffect - update storage

There's some duplication in there, for example 'cameraposition' and 'eyeposition', 'worldit' and 'worldinversetranspose' (there are others too).

If you want to do the job yourself and provide your own matrices then just do it. If you specify the values, DBPro will bow out completely for that shader from that point onwards.

There was a lot in those last posts of yours, so if I missed something, just pipe up.

Green Gandalf
VIP Member
21
Years of Service
User Offline
Joined: 3rd Jan 2005
Playing: Malevolence:Sword of Ahkranox, Skyrim, Civ6.
Posted: 11th Dec 2011 17:35
Ah, so its all hard-coded DBPro stuff rather than DirectX C++ routines?

Quote: "so if I missed something"


If you did I think you can safely ignore it.

I think you provided me with a link to the DBPro source at one point. I tried that but it wasn't clear to me how to simply download the code which I expected to be a trivial task. I believe I was being asked to download some other thing first. Do I need to do that?
IanM
Retired Moderator
23
Years of Service
User Offline
Joined: 11th Sep 2002
Location: In my moon base
Posted: 11th Dec 2011 18:48 Edited at: 11th Dec 2011 18:49
Quote: "so its all hard-coded DBPro stuff rather than DirectX C++ routines?"

Yes and no. DirectX is used to load the shader, then DBPro queries DirectX for the semantics used within the shader and reacts to those it knows about.

Quote: "but it wasn't clear to me how to simply download the code"

I used TortoiseSVN to access the code and keep a copy on my hard-drive. As I have commit access, I can also use that to update code within the repository too. I also use AnhkSVN to do the same from directly within Visual Studio too.

Alternatively, you can browse individual files within the respository: http://code.google.com/p/darkbasicpro/source/browse/trunk/%20darkbasicpro%20--username%20LeeBamberTGC/Dark%20Basic%20Pro%20SDK/Shared/DBOFormat/DBOFormat.cpp

Unfortunately, there are no other methods of accessing the code such as a zip archive or equivalent.

Green Gandalf
VIP Member
21
Years of Service
User Offline
Joined: 3rd Jan 2005
Playing: Malevolence:Sword of Ahkranox, Skyrim, Civ6.
Posted: 11th Dec 2011 20:09 Edited at: 11th Dec 2011 20:24
Quote: "then DBPro queries DirectX for the semantics used within the shader and reacts to those it knows about"


That's probably what david w and I would like to know about. How's that done?


Quote: "Alternatively, you can browse individual files within the respository"


That's what I wanted to do - but does that mean you need to know the filenames first?

Edit Thanks. I've got that file now and trying to make sense of it.

Login to post a reply

Server time is: 2026-07-09 23:11:43
Your offset time is: 2026-07-09 23:11:43