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 / Vertex position and calculation... little help please

Author
Message
paul5147
20
Years of Service
User Offline
Joined: 11th Jan 2006
Location: Hot & Sunny
Posted: 31st May 2011 07:08
Its a sparky`s collision dll command,i assumed thats how you would pick the polygon faces for your editing code as its the fastest way to get the vertex collision data you would need for this project of yours.
Daryn Alsup
18
Years of Service
User Offline
Joined: 5th Jul 2008
Location: In your head... dun dun DUN!!!!!!!!
Posted: 1st Jun 2011 22:34
well actually since the editing would be done in mesh data, I figured that after I make the meshdata following a memblock reconfiguration - that would arrange polys appropriately. IE, pick placing vertices in the memblock to automatically make the correct polys per plane, and a little seam work for the edges - I am not using sparkys

Jack and Jill went up a hill to fetch a pale of water... but Jill got tired of his s#%& so she shot him.
paul5147
20
Years of Service
User Offline
Joined: 11th Jan 2006
Location: Hot & Sunny
Posted: 3rd Jun 2011 21:34
Well i sugest you download it and give it a try,its free and makes what your trying so much easier,take a look at the code snippet below,its so easy to do vertex manipulation with,you dont even need to wory about memblock meshes, you can do it with the vertex data comands in real time,upto a point,and that is,trying to build meshes in real time just to bring the poly count down isnt allways the best way to speed things up.
It can take longer to edit a mesh data and rebuild the object than to just display the original.

uncapped this runs at over a 1000fps on my netbook,but a slightly modified version that has 16X16 tiles and only updates the meshes that are needed each loop (max of 4) soon drops this to only a 100fps,but simply displaying the 16x16 tiles it stays at over 500.
Poly count is not the ultimate way of speeding up your games.
Daryn Alsup
18
Years of Service
User Offline
Joined: 5th Jul 2008
Location: In your head... dun dun DUN!!!!!!!!
Posted: 9th Jun 2011 02:33 Edited at: 9th Jun 2011 02:38
alright, changing the plane size to 512, the segment count per plane to 64 and the number of planes to 32 = (8ft x 8ft per segment, 8*512*32=131,072 units. 131,072/5280 (or one mile in feet) = 24.824... miles) I need it bigger, perhaps using this method of creating large plane objects and using an array to store them, I could do the same thing over and over again, hide them when they're out of camera sight/range.

Plane set 1
code for 32 planes each 512 units big and with 64 segments each
plane set 2
code for 32 planes each 512 units big and with 64 segments each
Plane set 3
...
Plane set 4
...
Plane set 5
...
...
...
Plane set 10
...

What is the limit for DBPro and the number of vertices that can be drawn? is there a limit to how many vertices can be created? - I am shooting for a minimum of 100 miles and a maximum of 500 miles (sq Miles)

edit:
Also - I have a terrain shader that I like to use, is there any way to fog the plains like so... image attatched.

Jack and Jill went up a hill to fetch a pale of water... but Jill got tired of his s#%& so she shot him.
paul5147
20
Years of Service
User Offline
Joined: 11th Jan 2006
Location: Hot & Sunny
Posted: 9th Jun 2011 21:52 Edited at: 9th Jun 2011 22:02
Dont know for sure if theres a vertex limit for the whole scene,it may depend on your video memory,but there is as far as i know a limit per object of 65536 which could be a grid of 256*256,but i`ve never tried making one that big.
Is the view your going to give the user of this world from a fixed point or do they have free movement to explore from any angle and position.If its fixed you could cheat and only show say a 3x3 grid of the actual area on view and flat planes of all the surounding areas textured to give the effect of detail at a distance from the camera.You would then only have to hide/unhide a max of 5 tiles.It would be like a 2d tile engine in a way but with multiple layers,but yould only show the most detailed layer when up close.Thinking about it,it could be done without a fixed view as long as you couldnt move too far from the scene to show up many more than the 3x3 grid tiles or it would spoil the illusion.

Edit:
See from your image you decided to give sparkys a try,but as for the fog GG is probably the man for shader type questions around here.Or have a search through the how to wright shaders post that was sticked on here somewhere,if no help then look into any of Evolveds shaders,theres a website of his thats packed with some realy good shaders that are easy to follow and make work.
Daryn Alsup
18
Years of Service
User Offline
Joined: 5th Jul 2008
Location: In your head... dun dun DUN!!!!!!!!
Posted: 10th Jun 2011 07:07
So what I'm doing is, on the set of planes - cities will grow, based on the distance from the camera (camera range) the fog will cut off which objects are displayed on the screen - including terrain, buildings and so fourth - basically anything that is beyond the camera range will not be rendered to the camera - BUT, the movement of the camera will extend from the max distance to the max negative distance for the set of planes - while the distance from each plane will have a max (since I'm not making a 3d sphere out of planes, we don't want the user to zoom out so far that the camera range hides everything, yet we also want to prevent the camera from intercepting the terrain and objects on it at an ubber close range), so to be blunt:

1) The camera can only zoom in and out a max of "X" based on the camera's range
2) The camera must move to various areas like traveling from and to other cities.

Jack and Jill went up a hill to fetch a pale of water... but Jill got tired of his s#%& so she shot him.
Daryn Alsup
18
Years of Service
User Offline
Joined: 5th Jul 2008
Location: In your head... dun dun DUN!!!!!!!!
Posted: 11th Jun 2011 08:23 Edited at: 12th Jun 2011 21:09
G.G.!!! I figured out the serious lag, and Paul you've managed to show me how to get rid of it - or at least part of it.

The initial lag is due to the pick commands - primarily pick object. Because we have so many planes and we're scanning to see the 3d location from a 2d location on EACH plane, the frame rate suffers a severe blow! - removing the pick commands solved the problem as Paul's method proves - and, by manipulating it further, my frame rate increased significantly.

The final part of the lag is due to... (yes, G.G. - you were right) the shader.

I need to first - figure out how to change the location of pauls target object and allow it to follow the mouse position, then through some method, use collision detection to find which objects are closest to the marker object manipulated by the mouse - those objects will be scanned rather than the 1024 (32*32 plane square) currently entering into the loop.

Paul, if you can help me figure this out I will give you cookies.

G.G., I need to find a terrain shader that uses fog to use while terraforming. Something that uses four or more textures but doesn't use normal mapping in the shader, just the "normal" normal procedure. If you can direct me in writing or creating/finding one, i will give you a cake

Jack and Jill went up a hill to fetch a pale of water... but Jill got tired of his s#%& so she shot him.
Daryn Alsup
18
Years of Service
User Offline
Joined: 5th Jul 2008
Location: In your head... dun dun DUN!!!!!!!!
Posted: 19th Jun 2011 22:36
Okay here's an update which I am very happy about

1) I am going to use this method for different projects - (I bet this is news to any programmer )

2) If I used it for an RPG, the scale of the landscape would be much smaller, but because I am using it for a sim, each grid square will equal about 100 sq. feet. At that ratio, and with the planes being 512.0 units in size, each with 32x32 segments (512*32 plane segments*32 plane segments * 100 ft = Holy S***!!!/ 5280ft [[or one mile]])= Nearly 10,000 square miles. WOW!!!!!!!!!!!!

Here's the code, adapted for non-media use. Running on my machine (with a gig of ram and not the best v-card in the world) @ 55-45 frames a sec during non-edit mode and 44-34 during edit mode.

NOTE - I ahve reduced the grid unit scale size from 100 ft to 10 ft for this exercise - total size is 32 planes by 32 planes - each plane 512 units long and across, each with 32 segments by 32 segments.



@paul5147 - I had to tweak the collision object to get it to terraform without the slow down from the pick commands - without any media, using the pick commands gave me 0 fps - ouch.

There is still an error somewhere - something to do with the distance and hill drawing - maybe the object array and vertex position reading and changing - but I will keep going at it - if you see the solution at a glance, please let me know.

Jack and Jill went up a hill to fetch a pale of water... but Jill got tired of his s#%& so she shot him.
paul5147
20
Years of Service
User Offline
Joined: 11th Jan 2006
Location: Hot & Sunny
Posted: 20th Jun 2011 07:11
Nice to see your making some progress Daryn,glad to see your sticking with sparkys for this,there are a few commands i think you should check up on though that may help you.
SC_UpdateObject,this tells sparkys that the mesh data has changed and it resets its collision data for that object.
It can be quicker sometimes though to delete the DBpro object and the SC_DeleteObject and simply do SC_SetUpComplexObject on the new tile.You may have to run a few tests to see which is quicker for you.
Green Gandalf
VIP Member
21
Years of Service
User Offline
Joined: 3rd Jan 2005
Playing: Malevolence:Sword of Ahkranox, Skyrim, Civ6.
Posted: 20th Jun 2011 12:42
Daryn Alsup

Just seen your recent posts and questions especially the 11 June one. Sorry I missed that.

Can you post a simple version of your program, i.e. code and media but not the exe file (takes up unnecessary space), and I'll see if fog can be added easily? Email it to me if you prefer. I don't have Sparky's collision dll - looks like it's about time I did though .

There might be a delay in me looking at it as my desktop is ill at the moment (it's seeing the doctor on Wednesday ).

Regarding the vertex limit of 65536, I'm fairly sure that limit is per limb not per object. This means that very large objects can be split into limbs in DBPro. I've started work on a program that does that for you but it isn't complete yet. I'm not sure of the advantages of using many limbs rather than many objects. You get less control with limbs (some commands are only for objects and not limbs) but I think many limbs might have some performance advantages over many objects. I'm not sure though.

I vaguely recall there being a more obscure limit which depends on the vertex format and the extra structures required by shaders (i.e. tangents, binormals, etc). The moral there is that it's probably a good idea to stay well within the overall limit per limb.
Daryn Alsup
18
Years of Service
User Offline
Joined: 5th Jul 2008
Location: In your head... dun dun DUN!!!!!!!!
Posted: 20th Jun 2011 21:15
Well gg,

I am actually happy with my 512 sq unit sized plane, 32 by 32 planes, each with 32 by 32 segments (a grid face = 100 sq ft) that's like 9992 sq miles - size is fine. I was just curious as to whether there is a limit to total object made - not rendered. I can hide objects out of view.

As for vertex limit - there seems to be a problem when using arrays - I was thinking about writing an LUA file via DBPro function that stores locations of planes and groups the objects - replacing all the array data needed - it could include LODS to a finite size and push further than the array's max size - which is relatively low in comparison to this method of object drawing and manipulation.

BUT - alas - I am focusing on another thing at the moment lol - anyone familiar with NBC's "The Voice" - your's truly will be on the show for blind auditions - I am filling my day with music at the moment and will be distancing myself. Since you guys have helped me out so much with this and given me hints and tips and bits of knowledge - here's a little music for s***'s and giggles - and then back to the topic

PS - GG, I emailed you so check it and see the exe there. not posting here - I can't through a mock up as of yet - things aren't even near finished - give me a week and I'll have a basic program for you guys to fool with.

Jack and Jill went up a hill to fetch a pale of water... but Jill got tired of his s#%& so she shot him.
paul5147
20
Years of Service
User Offline
Joined: 11th Jan 2006
Location: Hot & Sunny
Posted: 20th Jun 2011 23:35 Edited at: 20th Jun 2011 23:36
Hi Daryn,hope all goes well with the audition.
Thanks for the music,have a gift for you as well,check the code snippet when you get chance,it may give you a few more clues as to how to manipulate the vertex data,and from here its a very short jump to using sparkys to pick the point you want to modify rather than a random point this uses.

Good look
Daryn Alsup
18
Years of Service
User Offline
Joined: 5th Jul 2008
Location: In your head... dun dun DUN!!!!!!!!
Posted: 21st Jun 2011 00:37
@ Paul5147
This is very cool, and very smooth in ways, but I need to understand what I am doing wrong with my code before I try and figure out what you're doing right in yours

If you run the code paul, (attached project file) you'll see that the problem is the object number, the pick distance and how hills are drawn - the simpler the code, the fast it reads. I am trying to use simple methods for complex results - sin(dist#/multiplier)*((value here) = a nice hill, through in some simple math and a fractal hill is made. U have to be able to terraform LIVE in the game. So I am gearing to use an external file for the tool type, and code run (so the user can mod terrain editing tools) and thus is the explanation of the problem in this:



Jack and Jill went up a hill to fetch a pale of water... but Jill got tired of his s#%& so she shot him.
Green Gandalf
VIP Member
21
Years of Service
User Offline
Joined: 3rd Jan 2005
Playing: Malevolence:Sword of Ahkranox, Skyrim, Civ6.
Posted: 21st Jun 2011 02:07 Edited at: 21st Jun 2011 14:04
I've got your email. Hope to look at the code carefully tomorrow.

Quote: "I don't have Sparky's collision dll - looks like it's about time I did though."


Looks like my brain needs fixing - it seems I've had that DLL for some time.
Daryn Alsup
18
Years of Service
User Offline
Joined: 5th Jul 2008
Location: In your head... dun dun DUN!!!!!!!!
Posted: 29th Jun 2011 01:04
Okay, I think I have figured out something - pertaining to the distance# function - which uses the tempX#, Y# and Z# location (vertices) and pickX#, Y# and Z#.

G.G. ran into errors with the vector ID used - that IAN M's plugin "Find Free Vector" will return 0 as a possible vector number that in current versions of DBPro cause the code to fail - as 0 is no longer a correct vector number.

For the life of me I cannot figure out why the click location (pick vectors) and vertex locations (tempX#, TempY#, TempZ#) are returning incorrectly - as the code seems to work in certain areas but not in others - (3d locations that is) You can terraform anywhere but not always to the same amount of terraforming detail - IE: height and seam(s). I don't understand why. I am continuing to look further into this issue but if anyone can catch the problem please say so - this is my first large scale terraforming app that for the most part (now) runs fairly smooth (minus the shader) hit me up if you find any thing.

Jack and Jill went up a hill to fetch a pale of water... but Jill got tired of his s#%& so she shot him.
Green Gandalf
VIP Member
21
Years of Service
User Offline
Joined: 3rd Jan 2005
Playing: Malevolence:Sword of Ahkranox, Skyrim, Civ6.
Posted: 29th Jun 2011 02:12
Quote: "G.G. ran into errors with the vector ID used - that IAN M's plugin "Find Free Vector" will return 0 as a possible vector number"



I found nothing of the sort. In fact the code you sent me does not use that function. Here is the Distance# function from that same code:



That function does not use IanM's find free vector function. Furthermore your Distance# function is only called once in the code:



You can see there that the value of vecNum corresponds to the variable length in the calling code. That variable is not defined or used anywhere else in your code so it defaults to an integer variable initialised to zero - and that is why your code fails in current versions of DBPro.

I've pointed this error out to you in two emails already (which you've seen). How many more times do I have to tell you?

Quote: "For the life of me I cannot figure out why the click location (pick vectors) and vertex locations (tempX#, TempY#, TempZ#) are returning incorrectly - as the code seems to work in certain areas but not in others"


Yes, I've noticed that with your code but haven't had a chance to investigate yet. I seem to be having trouble getting you to understand a much simpler problem with your code.
paul5147
20
Years of Service
User Offline
Joined: 11th Jan 2006
Location: Hot & Sunny
Posted: 29th Jun 2011 19:20
Hi Daryn,
I've broken this down into the simplest demo i can for you.
It shows how to use sparkys and pick object together to to get the distance and collision point under the mouse,you will see that the marker follows the mouse pointer around the plains reporting the collision object,position of collision and distance from camera to collision point.
If you want i can also post the code from earlier with this selection method in that lets you modify the terrain under the mouse pointer rather than at random points.

Hope this helps

Login to post a reply

Server time is: 2026-07-10 15:31:15
Your offset time is: 2026-07-10 15:31:15