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
Daryn Alsup
18
Years of Service
User Offline
Joined: 5th Jul 2008
Location: In your head... dun dun DUN!!!!!!!!
Posted: 9th Jan 2011 00:03
How was the food? Any difference in lag issues with the latest code?

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: 9th Jan 2011 00:11
Quote: "How was the food?"


Very tasty thanks.



Quote: "Any difference in lag issues with the latest code?"


Yes, it's better.

The new code still has the vertex count wrong:



As I said before it should be



Not sure yet whether that's the only problem.
Daryn Alsup
18
Years of Service
User Offline
Joined: 5th Jul 2008
Location: In your head... dun dun DUN!!!!!!!!
Posted: 9th Jan 2011 00:22
No it's not. I can't figure this out.

What do you do when terraforming like this... I gather you have in that you gave me the idea about arrays.

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: 9th Jan 2011 00:44 Edited at: 9th Jan 2011 01:17
Your code is only changing the vertices near the central object. Is that intentional? I assumed you'd want to change the vertices near the picked location.

I suspect you've forgotten that all your objects initially have the same vertex data - even after you've repositioned them. In other words you don't seem to have allowed for the XZ translation. Was this line supposed to fix this?



If so, I don't see how it can.

All you need to do, if I've understood correctly, is to add the object's XYZ position to the individual vertex XYZ positions before calculating the distance.

You also need to repeat the procedure for the 8 neighbouring objects (which your earlier code might have been doing).

Edit This is what you need:



All you need to do now is do the same for the other 8 objects so you don't see the black gaps along the seams.

Hope this helps.
Daryn Alsup
18
Years of Service
User Offline
Joined: 5th Jul 2008
Location: In your head... dun dun DUN!!!!!!!!
Posted: 9th Jan 2011 01:24 Edited at: 9th Jan 2011 01:32
Thank you GG! that solves that issue... moving on to the arrays... and I feel so silly... thanks for teach'n the new dog new tricks

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: 9th Jan 2011 12:15
You're welcome.

Your code has shown me how easy it is to do terraforming in code so hopefully I've learnt something useful too.

Don't worry about making mistakes, we all do it when we try something new (and other times too sadly ).
Daryn Alsup
18
Years of Service
User Offline
Joined: 5th Jul 2008
Location: In your head... dun dun DUN!!!!!!!!
Posted: 10th Jan 2011 06:29 Edited at: 10th Jan 2011 06:42
Question... how exactly would I place the array strip of code... I'm confused. Since I very the brush size based on the distance from the pick vector and inc the values based on a 1-2-3-4-5, 5 being the area most near the pick vectors... how do I normalize/smooth the array values

EDIT W/ ATTACHMENT:
Here's the bit of ARRAY USAGE but there is an error that I can't locate... Care to have a go at it?

If you move the mouse up and down while mouseclick()=1, it will edit the vertexdata... however if you move to the top/bottom of the object and raise it the vertexdata is only edited on the current pick object. No problem there, I know this will change for the smoothing effect... but if you move to an object above or below the pick object being terraformed, the object's ends reset - rather than match the opposing sides. (I've only (tried to) set the top and bottom objects of the pick object to re-adjust.)

Here you are:

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: 10th Jan 2011 11:52
Quote: "Question... how exactly would I place the array strip of code... I'm confused."


If I've understood your method correctly (as in your 25/26th November snippet) you probably don't need this now since you modify each vertex according to distance from the picked position. So if two or more vertices are in the same position (along edges and at corners for example) then they should get adjusted by the same amounts in your code. Of course that runs the risk of accidental arithmetic errors on boundaries of tests like "if dist# < 5.0". Because of limited precision problems two "identical" vertices might actually be at very slightly different positions so one fails the test and one passes. In my experience such "remote" possibilities become certainties when a program becomes public. So, ideally, you will need to address this issue at some point but I doubt it's critical for the moment.

Quote: "No problem there, I know this will change for the smoothing effect... but if you move to an object above or below the pick object being terraformed, the object's ends reset - rather than match the opposing sides."


Sounds like a logic error in your code somewhere. Now that I've got a fairly clear idea what your code is doing I'll take a closer look. Might not have time till tomorrow though.
Green Gandalf
VIP Member
21
Years of Service
User Offline
Joined: 3rd Jan 2005
Playing: Malevolence:Sword of Ahkranox, Skyrim, Civ6.
Posted: 10th Jan 2011 19:11
Is this any better? The code now adjusts the surrounding objects as well.



I've also deleted several lines that didn't seem to be doing anything, added "sync" etc, and simplified the incrementing code so it doesn't adjust a vertex more than once.
Daryn Alsup
18
Years of Service
User Offline
Joined: 5th Jul 2008
Location: In your head... dun dun DUN!!!!!!!!
Posted: 10th Jan 2011 23:36 Edited at: 11th Jan 2011 00:54
Okay! I can "grow" this TY I understand now... at least what I can gather at a glance. I'll go over this again and again to perfect it. On a side note, I can't seem to fog the objects.

Right now the strip is making a 5X5 plane square with each of the five planes containing 50X50 segments at a size of 250X250 units. If you increase the scale value at the top it auto-sizes the planes. Say if you adjust the scale value to 20... that's a lot of objects and vertices to display. So we do a distance check from the camera to each object. If the distance is too great, we hide the object. The trouble is (using fog) to fade the areas of the map not being displayed to the areas of the map that are. Any ideas why fogging wont work? I've created a single plane and fogged it... but something causes it to not work on the multi-plane map thingy :$

Again many thanks! Have a cookie

EDIT:
Oh yeah... shaders and fog... ehhh. I'll have to in corporate a custom fog shader wont I?

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: 11th Jan 2011 11:25
Quote: "Oh yeah... shaders and fog... ehhh. I'll have to in corporate a custom fog shader wont I?"


Yes, it isn't difficult. Have a go at it and post back if you get stuck.
Daryn Alsup
18
Years of Service
User Offline
Joined: 5th Jul 2008
Location: In your head... dun dun DUN!!!!!!!!
Posted: 11th Jan 2011 17:34
Okay i need some brainstorming help... or for that matter a little DBPro help. Where exactly is the fog shader located at? and B) if I can't incorp. it into the terrain shader itself, where can I find a good cube/square fog shader?

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: 11th Jan 2011 19:04
What sort of fog do you want?

Fog based on:

distance from the camera

or

camera z depth

or

distance from the pick object point?

Any of these can easily be incorporated into the shader.
Daryn Alsup
18
Years of Service
User Offline
Joined: 5th Jul 2008
Location: In your head... dun dun DUN!!!!!!!!
Posted: 11th Jan 2011 19:14 Edited at: 11th Jan 2011 19:34
Distance from cam preferably.

EDIT:
I'm rather new to the world of shader coding... but I can often get "shaders to do" what I want them to do. Fog however is something I haven't experimented 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.
Green Gandalf
VIP Member
21
Years of Service
User Offline
Joined: 3rd Jan 2005
Playing: Malevolence:Sword of Ahkranox, Skyrim, Civ6.
Posted: 11th Jan 2011 21:44
Quote: "but I can often get "shaders to do" what I want them to do"


That's a good start.

I'll have a look at the shader. But, really, why do you want to use fog for this? If the aim is to reduce the number of objects and polys being rendered why not, for example, simply exclude everything that's outside a 5x5 grid centred at the current pick object?

The only benefit of fog in this case is that it might look more artistic.
Daryn Alsup
18
Years of Service
User Offline
Joined: 5th Jul 2008
Location: In your head... dun dun DUN!!!!!!!!
Posted: 12th Jan 2011 02:06
Working shader w/ fog (works in Dark Shader anyway.) can you tell me why it wont work in dbpro?



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: 12th Jan 2011 12:39
That's a complicated shader!

Anyway, looking at the fog part, your fog formula comes down to the following (which seems unnecessarily complex)



What do you think is happening when those are evaluated in sequence using the values set in the shader?

Among other things you've mixed coordinate systems in the final formula: EyePosition is in world units and IN.pos is in object units. This is similar to the point we discussed the other day - all your objects have the same XZ coordinates. It's their individual world matrices that hold the information about their actual position in the world.

Put some typical numbers in and you should be able to see what's happening.

By the way, the shader seems to "work" in both DBPro and Dark Shader - just not in the way you probably want.

How do you want it to work incidentally? I can guess, but ...
Daryn Alsup
18
Years of Service
User Offline
Joined: 5th Jul 2008
Location: In your head... dun dun DUN!!!!!!!!
Posted: 12th Jan 2011 23:38 Edited at: 13th Jan 2011 01:51
If fog mode = 1 or greater than one, the fog fades from top to bottom, and reverse for fog mode 0 or less then 0.

What I am aiming for is

1) Have the fog vary in density (XYZ axis') based on camera position (y axis only) This is to achieve a fade from ground level to arial view (the fog would appear to surround the objects based on a radius)

2) When you move the cam at ground level, the radius doesn't change in size but rather in position.

3) The color can be changed to match the BG in DBPro

4) The density can be changed in DBPro along with start and fall off

I have no clue how to achieve this... but I am focusing on the shader fully at the moment. So any tips for writing or math help is appreciated. I will continue to fool around with it for the day.

EDIT: a rather simple question

How do I convert a 255 color integer into a 0.0 to 1.0 float? (yes color)

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: 13th Jan 2011 00:27
1) Then use a formula which uses EyePosition.y
2) Use a distance based on the pick and object world XYZ positions
3) Your shader does that already
4} Work the formula out on paper first using simple algebra - then replace the algebra with the appropriate shader variables.

Your shader code uses the right sort of fog calculations already - it's just the distance details that need cleaning up. Have another go and if you're still stuck I'll post something tomorrow. (I won't change the rest of the shader even though I suspect it is unnecessarily complicated.)
Daryn Alsup
18
Years of Service
User Offline
Joined: 5th Jul 2008
Location: In your head... dun dun DUN!!!!!!!!
Posted: 14th Jan 2011 05:12 Edited at: 14th Jan 2011 08:25
Okay I need help with normal calculation. I can set the normals for all the objects at the beginning of the program, but setting the normals will require some vector and algorithm use... any tips anyone?

As for the fog shader, I gather how to fix the issue.

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: 14th Jan 2011 13:18
Quote: "Okay I need help with normal calculation."


I was wondering when that would come up.

The simplest way of doing this is to use the built-in set object normals command. This works fine except for the seams between objects where lighting calculations can show a visible seam from certain light directions. You would then, ideally, fix the seams as a separate step using the array idea I mentioned ages ago.

Anyway, give the set object normals command a try first. You use this after unlocking the vertex data. Only use it on objects which have changed though.
Daryn Alsup
18
Years of Service
User Offline
Joined: 5th Jul 2008
Location: In your head... dun dun DUN!!!!!!!!
Posted: 14th Jan 2011 13:47 Edited at: 14th Jan 2011 13:49
Well - I gather the use of that command... but try using it in one render consisting of over 400 objects (change the scale value to 20) Ouch on performance and FPS. I am fooling around with Vector3 commands and the Transform Normals Vector3. To no avail although some things have come relatively close.

First I would like to clarify that I know what a normal is and how its calculated, it's creating a method to do so that I'm aiming for. Seems stupid that I can't just figure this out... but it's not like I can just recall the math face shadow on the basis of reflection and intensity off the top of my head. :/

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: 14th Jan 2011 14:23
Quote: "but try using it in one render consisting of over 400 objects "


Why do you want to do that? You're only changing 9 objects per render.

As I said:

Quote: "Only use it on objects which have changed though."
Daryn Alsup
18
Years of Service
User Offline
Joined: 5th Jul 2008
Location: In your head... dun dun DUN!!!!!!!!
Posted: 14th Jan 2011 14:35 Edited at: 14th Jan 2011 14:37
Well take a look if you will... note the rem'd out portions are there as a result of my vector/matrix4 testing.

It can reduce frame rate and I'd rather prefer to use an alternative method but that's me. I am trying to keep performance up. You can use various keys to alter the shader values.

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: 14th Jan 2011 16:48
Note for future reference - there's no need to have exe files in your download file and two in each download is excessive.

I'll take a look.
Green Gandalf
VIP Member
21
Years of Service
User Offline
Joined: 3rd Jan 2005
Playing: Malevolence:Sword of Ahkranox, Skyrim, Civ6.
Posted: 14th Jan 2011 17:10
I see what you mean.

The following simple change improves things somewhat (it only recalculates an object's normals if at least one vertex has changed):



Incidentally when you raise the terrain you should be able to see the seams I was talking about.
Green Gandalf
VIP Member
21
Years of Service
User Offline
Joined: 3rd Jan 2005
Playing: Malevolence:Sword of Ahkranox, Skyrim, Civ6.
Posted: 14th Jan 2011 17:15
Quote: "First I would like to clarify that I know what a normal is and how its calculated"


Do you? Your code suggests you don't. Or have you corrected it?

Daryn Alsup
18
Years of Service
User Offline
Joined: 5th Jul 2008
Location: In your head... dun dun DUN!!!!!!!!
Posted: 15th Jan 2011 00:31
I thought it was
Vec. 1 = vertex 1 x,y,z
Vec. 2 = vertex 2 x,y,z
Vec. 3 = vertex 3 x,y,z

subtract vec2 from vec1= newvec1
subtract vec3 from vec1= newvec2

cross product into newvec3
normalize newvec3

am I calculating which vertex is which wrong?

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: 15th Jan 2011 01:28 Edited at: 15th Jan 2011 01:29
Quote: "am I calculating which vertex is which wrong?"


Sort of. You can't use any just three vertices and get sensible answers - they need to form a triangle which is more or less parallel to the surface. Your choice doesn't do that. Draw it.

If I want a normal at a point (x,y,z) in a grid (like your terrain objects) then I usually use the four vertices which are North, South, East and West of that vertex (in terms of X and Z that is). The North-South pair gives one direction, the East-West pair the other. That will give a normal centred at the vertex of interest. The edges are slightly different of course and can't be centred that way.

You can do it using polys from the object but they won't be centred on the vertices so will be slightly off. But that's not your problem. I suspect you've assumed that successive groups of three vertices form polys in your objects. They don't. Just print them out for a plain subdivided 4x4 to see what I mean. I believe IanM's Help file explains the layout for his plains.
Daryn Alsup
18
Years of Service
User Offline
Joined: 5th Jul 2008
Location: In your head... dun dun DUN!!!!!!!!
Posted: 15th Jan 2011 01:37
Yes ah I see... well then in regards to that, are you aware of or have heard of setting the normal data from index data rather than vertex data? If I'm right, the array of vertices for each index reports the vertex number(s) being used to draw that index (or poly) - if I can gather n,s,e,w vertices from index data - would it do as it suggests and save me the trouble of writing additional lines of code? - seems like something I'll have to try.

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: 15th Jan 2011 11:12
Quote: "if I can gather n,s,e,w vertices from index data - would it do as it suggests and save me the trouble of writing additional lines of code?"


How would that help? You still need to calculate the normals.
Daryn Alsup
18
Years of Service
User Offline
Joined: 5th Jul 2008
Location: In your head... dun dun DUN!!!!!!!!
Posted: 16th Jan 2011 08:19 Edited at: 16th Jan 2011 08:21
So say a cube holds 36 indices. the first index array reports vertices 0 through 3. If I gather that north and south are vertices 1 and 3 and east and west are 0, 2. Using this method I could calculate how faces are drawn and thus the angle from which normals are drawn... for instance vertex positions for vertex 0 and 2 would be entered into vectors, subtracted from the vertex 1's vector and then cross product and normalize the results... this is a normal correct?

Likewise the same would be done for vertices 1,3 and 0 and their corresponding vectors.

Am I mistaken?

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: 16th Jan 2011 11:52 Edited at: 16th Jan 2011 11:58
What I have in mind is the following diagram which represents a small section of one of your terrain objects viewed from above:



In that diagram the blue dot is the vertex of interest (no need to complicate matters by working with index data) and the four immediately adjacent vertices are shown in black and marked N, S, E and W.

Suppose pN, pS, pE and pW are the position vectors for the vertices N, S, E and W, and p is the vertex of interest. Then you can use your method of working with two direction vectors if you set one equal to pN-pS and the other to pE-pW. Then take the cross-product and normalize it as in your code. You'll need to experiment to see which way round the cross-product should be - I can never remember the rule .

That works for all the interior vertices. For the edges the simplest thing to begin with is to use differences such as pN-p and pE-p instead. That may give visible seams but is simple to implement and enables you to test the main logic.

Once that's working we can discuss the seams.

IanM's Matrix1 Help file tells you the numbering of the vertices.

Alternatively you can work with one big array for the whole terrain (which is what I do) but the details are messy either way.
Daryn Alsup
18
Years of Service
User Offline
Joined: 5th Jul 2008
Location: In your head... dun dun DUN!!!!!!!!
Posted: 16th Jan 2011 13:18
Quote: "Alternatively you can work with one big array for the whole terrain (which is what I do) but the details are messy either way. "

You mean to say that all the vertices for say 400 objects can be stored in one array... 50 segments up and across each? I will test this... seems too large but what the hey... I wont know unless I try.

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: 16th Jan 2011 17:00
Quote: "You mean to say that all the vertices for say 400 objects can be stored in one array... 50 segments up and across each?"


Yes - but you'll obviously neeed to check the overall size limits for an array. I don't know what they are. The advantage of doing it that way is that you don't any seams to worry about, just the four main edges. When you've finished calculating the changes you just copy the new values into the relevant vertices of the affected limbs. I don't know what the speed trade-off is though.

Quote: "seems too large but what the hey... I wont know unless I try"


Yep, you can learn a lot by experimentation - and it's often the easiest and quickest way.
Daryn Alsup
18
Years of Service
User Offline
Joined: 5th Jul 2008
Location: In your head... dun dun DUN!!!!!!!!
Posted: 24th Jan 2011 21:34
Okay GG now I need some assistance with an LOD system. What I've done is create a global dim and stored all the vertices for each object. When you terraform the terrain, everything is updated within the array. This array is then entered into memblock data and used to create a mesh. For whatever reason the app crashes silently. the array looks like this: (You'll have to forgive me, I'm not on home pc so the code below is from memory as internet is down for the time being... I will try and get the correct code up.)



Again, this is from memory so make sense of what you can. but for whatever reason - compiling will cause the program to crash silently... no error message. If I f6 debug I get a C++ runtime error (program ended in an unusual way message)

The function with the memblock is only used with the distance# function seen in earlier posts... when an object is too far away, this function will cause those objects to be simplified. I will try to get some code up soon. I have the fog working, I am still fumbling with the normals, I think now that I have this global array I can use values from each normal called and see where v ertex positions are that way I can normalize the edges... in theory. Anyway, if you happen to know whats wrong or why it crashes or where I can read more... I'll say it now THANK YOU!

-Daryn

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: 24th Jan 2011 22:20
Have you allowed for the fact that mesh memblocks are based on unwelded groups of three vertices corresponding to successive polygons? Hence the original weled vertices should appear several times over in the memblock.

Why use memblocks for this anyway? If you have one big array for the full LOD object then why not make smaller ones by using just every second or fourth or eigth vertex as necessary? You just need to make sure that you use appropriately divisible meshes as your starting point. In fact why not make the initial LOD objects beforehand in the same way as before - then just edit the vertex data as necessary?

Or have I misunderstood what you're trying to do?
Daryn Alsup
18
Years of Service
User Offline
Joined: 5th Jul 2008
Location: In your head... dun dun DUN!!!!!!!!
Posted: 26th Jan 2011 05:34
okay well here's the full decription of what im trying to do.

Large (HUGE) terrain right, two kinds of views. City and regional. The purpose of the lod is purely for regional and maybe city view later. I have tried making a type and using a global dim to access it. The trouble is the pick commands. If I increase the size of the pick object command's highest object number, the array is invalid... or out of bounds. If I retain the same object count and just add to the lod objects to the object array (allowing the edges of each pick object to align) only objects near enough to lod objects will edit the lod object. If I return two kinds of pick objects I have to double the code length for vertexdata commands.

the easiest way at the moment that is working - and barely allows 3 frames a sec, is creating an array for the number of objects for the terrain there are and have the corresponding object number (in the array) = the lod object... I hide one object and show the lod object based on distance from camera. If the object is not visible or hidden, the lod object is edited instead.

I am going to try using an lod array and object array and see if I can get the for-loop to step according to the segment amount per mesh... but memblocks seemed simpler and shorter... wtf isn't there a way to create welded verts in DBPro... it contradicts the name.

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: 26th Jan 2011 11:44
Quote: "If I increase the size of the pick object command's highest object number, the array is invalid... or out of bounds."


I'd need to see code before I could comment on that.

I'm not really sure why there's a problem here. How many LODs are you using and do you have LOD objects for each original object? Could you simply maintain separate ranges of object ids for each LOD and check eack range separately according to pick object?

Actually, for editing purposes, wouldn't you want to work with the highest LOD, make the changes to the vertex data array, and finally copy the results into each affected LOD object?

Quote: "but memblocks seemed simpler and shorter"


Some people swear by them but I find they just add an extra layer of complication.

Quote: "wtf isn't there a way to create welded verts in DBPro... it contradicts the name"


I think you can - either by using the index data options in the vertexdata commands or by using some of IanM's plugins.

But I see no need for this. Why not create your LOD objects from IanM's plains in the same way as before (I think that's how you created your objects if I recall correctly)? For example:

Main object



First LOD object



Second LOD object



and so on. Your objects will automatically be welded then.

Then you can maintain a single vertex data array and just make sure you copy the correct info for each LOD as necessary.
Daryn Alsup
18
Years of Service
User Offline
Joined: 5th Jul 2008
Location: In your head... dun dun DUN!!!!!!!!
Posted: 9th Feb 2011 20:11
Wow - 90 posts... heh heh.

Okay so here's what I've done...
1) terraform the main object
2) in the same terraforming strip of code, terraform visible and non-visible LODs
3) Transition between LODs
4) Fog
5) SIMPLE normal mapping

`Now comes de-seaming. If I gather this thought, I suppose I could grab the distance from the main objects vertex (Since the LOD is 1/2 the size in vertices, the main object will have a vertex placed in between the LODs vertices) and move the main object's vertices (the main object's center vertex on the edges where LOD meets the main object) to the closer of the two vertices of the LOD.

Is this the best method of deseaming?

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: 18th Feb 2011 20:32
Hey diddle, diddle - the cat and the fiddle; the cow jumped over the BUMP!

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: 18th Feb 2011 20:51
Quote: "and move the main object's vertices (the main object's center vertex on the edges where LOD meets the main object) to the closer of the two vertices of the LOD."


I don't think I would do it that way. I would just move the higher LOD object's vertex to the average of the lower LOD object's two vertices and so on down the LOD chain. Then recalculate the normals of the modified vertices.
Daryn Alsup
18
Years of Service
User Offline
Joined: 5th Jul 2008
Location: In your head... dun dun DUN!!!!!!!!
Posted: 29th May 2011 23:19
Okay so here's my problem. I need to cut the poly count even more. This is useful if the camera is always at a constant distance from one plane/plain... but forget viewing say, ALL of them. Since I intend on using this in a city sim, with regions - not being able to view many plains at once is a -------------- to the outcome of my game. SO, that said, I wondered if it would be possible to do the following.

1) Instead of lod objects, let's keep it simple - I can designate each plane (approx 256x256 if size = desired by user) has NO SEGMENTS. Then, if the user decides to terraform the region, based on precalculated locations, we convert the object and load into a memblock, position the vertices based on where the user clicked and release the memblock to show what he/she has terraformed.

2) In theory, if we have 1 plane = 256 DBpro units, and have precalculated that if the entire plane is terraformed, there can only be a max of 64x64 segments per plane, then of the 256 planes, each capable of having 64x64 segments, only one will have been terraformed, and therefore the entire vertex count will be dramatically lower then previous method(s).

3) I would have to designate a radius from the click location to tessellate from. Since the object is shaded and loaded into memblock data, I can edit the uv data there as well as the normals.

4) This would increase framerate (duh)

So, anyone mind helping me tackle this? I'm fooling around with it now, but just want to make sure I have a teacher over my shoulder lol

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: 30th May 2011 02:04
its an older post so BUMP

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 &amp; Sunny
Posted: 30th May 2011 12:05
Hi Daryn,are you planing on using the built in LOD commands,a dll,or coding your own.I do have a little experience with the built in commands which seem ok as long as you build your landscape models well.I tend to make one large landscape height grid in a common aray,then sub devide it into an 8 by 8 grid of objects,LOD objects use either all the points for the nearest, every second point for the mid LOD and every fourth point for the far LOD. The objects then remain the same size but with fewer polyies,just what you need for LOD.The down side is the edges dont line up well if there is a sudden shift in height from vertex to vertex but if you set up the LOD ranges right you dont get close enough to see this.
I have some code here for you to try,if you weant to see the LOD in action then scroll down to the 'global wf' and set it to 1.
read through the code first and save it into a folder before you run it as it sets up folders to save all the objects and textures for later use and change the names if you want.
It also uses EZRotate,if you dont have it then change the 'global ez' to 0 and delete the code thats in 'make_normals' function that looks like this

Write now for the whole code,its rather large and does a lot more then LOD but it shows the principles.

Hope this helps,i have a lot of other code for vertex manipulation as well if your still stuck,but i have to say that trying to implement LOD at this stage is a bit late,i think you you may find its easier to design the code with it in mind from the start than add it in later,i know i tried it the hard way first!
Daryn Alsup
18
Years of Service
User Offline
Joined: 5th Jul 2008
Location: In your head... dun dun DUN!!!!!!!!
Posted: 30th May 2011 16:46
@paul5147:
There are no predetermined landscapes (advanced or otherwise) - the terraforming is done to several planes at one time, through an array, with (using the previous method G.G. was so kind to help me out on) many lod objects. - No, I am not using the LOD commands, I am simply reducing the poly/vertex count based on teh distance from the camera. As you zoom out, the user(s) will be able to see the entire region (Which can be as large as the exact distance from San Francisco, CA to Portland OR - given that one grid square = 3 cubic feet)

The previous method I was using was entailed with an lod system - a set of three objects per base object - (in other words, when you terraform one object, you're actually terraforming 4 - each with a lower vertex count to the power of two) however, this method - which caused normal mapping to take up A LOT of the performance and A LOT of resources, made terraforming a region equivalent to breaking up a section of land the distance from San Francisco to Portland IMPOSSIBLY SLOW! - SO, what I am trying to do now is the following:

All the planes used as the terrain object - the segments of each plane (Okay, if you follow me - one plane has 64 segments by 64 segments - which tell us where the plane's vertices will be) If there are 256x256 planes, each with 64x64 segments - you gather that is a lot of objects and vertices right? - So What I am trying to do is store the positions of each vertex - but not actually segment each plane - and here's why...
If I tessellate and change the meshdata for each plane ONLY if the user decides to terraform an object (where he/she clicked) then I would use THE LEAST amount of vertices and polys.

Easy to get image demonstration attached, hope you gather what I am talking about

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 &amp; Sunny
Posted: 30th May 2011 17:54
Hi Daryn,if your not going to segment the tiles other than the one your editing then what do the others show up as,flat?
Are you trying to delete/rebuild all the tiles every loop to show the changes caused by editing?
I have an editor that works on a 32*32 tile grid with each tile split into 64*64 vertex data and that works pretty much in real time if you limit the draw distance correctly,i can post up the code for that if you like,256*256 wouldnt make any difference because of the clipping that DBPro does for you,its set to show roughly about an 8*8 tile grid at any one time.
Daryn Alsup
18
Years of Service
User Offline
Joined: 5th Jul 2008
Location: In your head... dun dun DUN!!!!!!!!
Posted: 30th May 2011 18:06 Edited at: 30th May 2011 18:21
Well - what I am intending to do is tessellate - if you're hovering over the seams of two/four planes, then tessellation occurs on both/all four planes based on the pick location of the mouse (in theory for the next part) in direct relation to the predetermined 'possible' vertex positions. If I can gather how to tessellate planes and they remain seamless - then I can apply a hybrid lod system from the one I learned (via G.G.) and being able to position vertices accordingly - as to eliminate gaps.

(if you'd like, earlier in the posts, i provided code and exe to run, the terrain consists of many planes aligned and equal in segments count based on distance - so if you're 'x' amount away from a plane, it has 64x64 seg. - then 32x32, then 16x16 then 8x8 and so on - the trouble was that even then, large landscapes still use too many vertices/polys to keep the framrate high enough for a city sim.)

Again, I'm telling you that I'm NOT editing one plane at a time, just simplifying how many vertices there are in total when you add ALL the vertices from ALL the planes - IE - the starting state of the unterraformed terrain will have 6 vertices per plane object unless terraformed by the user, which will correlate to how many vertices there are for all 256x256 planes.

If it isn't terraformed by the user, it remains flat.

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 &amp; Sunny
Posted: 30th May 2011 21:04 Edited at: 30th May 2011 21:20
I get all that Daryn,but have you actualy tried to build a 256*256 tile array with 64*64 index array for each tile.I understand that in the begining you will only have a plane made up of either 4 or 6 vertex´s depending on the type of data structure you use for your objects,but as each one is edited you will run into problems.

Try changing the tile_sz variable to add more tiles into the program when you get much above 32 it will probably fail,it seems to depend on video memory on various machines,my laptop can handle 64*64 tiles but uses as much shared memory as it can get,my desktop has a fixed amount of video memory and fails above 32.
If you change the variable sz which is how many columns and rows the tile is made of then the lower it gets the more tiles you can have,so say each tile starts off flat 2*2 then you can have 256*256 tiles,but as soon as they get devided up more you will run into problems.
The way i get around this with my editor is limiting the tiles on display and if i need to go over say a 16*16 tile array to be safe on most machines is by deleting or creating the objects on the fly but this does take time.
Daryn Alsup
18
Years of Service
User Offline
Joined: 5th Jul 2008
Location: In your head... dun dun DUN!!!!!!!!
Posted: 31st May 2011 00:37
Quote: "SC_SETUPCOMPLEXOBJECT obj,0,2"


what is this ^^^ supposed to do/be - I'll try this out to see what it does once it works

Jack and Jill went up a hill to fetch a pale of water... but Jill got tired of his s#%& so she shot him.

Login to post a reply

Server time is: 2026-07-10 17:25:03
Your offset time is: 2026-07-10 17:25:03