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.

Newcomers AppGameKit Corner / Memblock mesh issues

Author
Message
James H
17
Years of Service
User Offline
Joined: 21st Apr 2007
Location: St Helens
Posted: 18th Nov 2020 22:02 Edited at: 18th Nov 2020 22:27
Link
Hi folks,

So I've been trying to get this code to work, it's basically a memblock mesh terrain from a heightmap. I have this horrible issue where heights don't match across one diagonal line stretching from bottom left to top right of the terrain, which can be seen by compiling the snippet. I have had this issue several times before over the years in DBP code but managed to solve it, however this time I have spent more than a day stuck on solving this in AGK. I am creating a rolling terrain so this is a smaller part of a bigger thing. If you change lines 403, 409, 410 in line with the associated rem statements on the end of each line, the seam can be resolved...but then the heights are messed up. This is done in the heights338() function

The heightmap is 51*51 because the mesh tile layout is 50*50 which means there is always an extra row of vertices to deal with in both +x and +z directions.

**EDIT** I forgot to mention that when I was debugging I had noticed I am missing a whole row of tile heights and every row slides across by one tile of heights each time the cycle passes the end and moves up the line in mesh memblock/down the line in hmap texture memblock

So that is the first problem I need help with. The second is the vertex colours, I don't seem to be able to get individual vertex colours, just whole triangles, this is also immediately obvious when the code is compiled. Further to that the colour of the triangle appears to be determined by a combination of all 3 vertices' colours. This is done in the layout338() function. So is it a bug, is itt by design, can each vertex be individual? At first I thought I need a shader maybe as it looks like AppGameKit produces standard shaders when none are used, or something like this(in help files). I have loaded a 5k object into AppGameKit that was created with memblock meshes in DBP which has individual vertex colours. They do show up in AppGameKit so if default shaders are generated on compile then a shader isn't the issue right?

That leads to me the third "issue"...what's up with said generated shaders, can we get access to them?

The fourth issue is more of an oddity I noticed that perhaps someone can explain...I have loaded a 5k object into AppGameKit and checked out the contents of the memblock mesh of it to find that the attribute string "position", is valued at 12 bytes instead of 8. The helpfile states that blanks will be used to pad out to nearest 4 bytes as the format appears to rely on steps of 4 bytes. Now the other attribute strings values are fine (I've read that 1 character is 1 byte) when rounded up, but "position" shouldn't need padding with an additional 4 blank spaces should it? I also checked the meshes of the command generated primitives and got the same result. Anybody got any clue?

Win 7 Pro 64 bit SP1, AMD A4-5300 APU 3.4GHz, 8GB DDR3, NVidia GeForce GTX 750 1GB GDDR5, ASUS A55BM-E

Attachments

Login to view attachments
Back to top
Profile PM
blink0k
Moderator
11
Years of Service
User Offline
Joined: 22nd Feb 2013
Location: the land of oz
Posted: 19th Nov 2020 02:40 Edited at: 19th Nov 2020 02:43
Link
GetObjectMeshPS/VSSource() to get the source code for a shader

Still figuring out the other stuff

AGK has Get/SetGetMeshMemblockVertexU/V/X/Y/Z etc Maybe you could populate the header and use those functions rather than poking values into the memblock.
My logic is it will be using AppGameKit to generate the values so it might avoid and nuances (If that makes sense)
Back to top
Profile PM
James H
17
Years of Service
User Offline
Joined: 21st Apr 2007
Location: St Helens
Posted: 19th Nov 2020 04:43
Link
Thanks, to do the header means you then have an offset value anyway - which can be added to the same position value used by the get/set memblock xyz norm xyz etc commands so its just as easy to do either. That said, when I'm done I will be testing if there is a speed difference between use of poking in memblock and the mesh commands. The main reason for needing to poke around is normals, and tangent/binormals required for certain shaders...or at least that was the case in directx.

I don't know how I missed those commands for getting shader sources! I mean i have stared at them so many times as they are right next to the others hahaha, I had noticed them I just didn't read them as I very wrongly assumed they simply would return the assigned ID of the shader applied to a specific mesh. I notice its a single string...I guess that is why a load of the raw shaders from shader pack templates are so annoying to read!

Regarding the vertex colours...i have noticed that the 5k objject I loaded in AppGameKit (it showed vertex colours do work individually), has index data. Now i made that from a memblock mesh in DBP and saved it with a native command, I know I didn't index anything so the save command must have produced it. I checked the .x file manually in notepad and sure enough there are a lot of indices...15000 - one per vertex! I am guessing this has something to do with why my memblock mesh from code in AppGameKit produces a single colour between the 3 vertices of any polygon as I have not added any index data.
Win 7 Pro 64 bit SP1, AMD A4-5300 APU 3.4GHz, 8GB DDR3, NVidia GeForce GTX 750 1GB GDDR5, ASUS A55BM-E
Back to top
Profile PM
James H
17
Years of Service
User Offline
Joined: 21st Apr 2007
Location: St Helens
Posted: 19th Nov 2020 21:38
Link
Okay so it seems all I needed was a good sleep...the irony being that for the first day I couldn't sleep because this was bugging me, when all i needed was sleep, go figure!

Basically remove lines 387 to 403 from the snippet in first post and put in the above snippet in its place.
Pretty much just added the shift variable and changed the value at the end of the line with the remark starting "change 0 to 1"...which was in line with what I suspected, just needed that kip!

Haven't done anything on the vertex colour/indices thoughts I had just yet or progressed any thoughts to why the string "position" has a size that seems odd. Will post back if ever I do.

Cheers
Win 7 Pro 64 bit SP1, AMD A4-5300 APU 3.4GHz, 8GB DDR3, NVidia GeForce GTX 750 1GB GDDR5, ASUS A55BM-E
Back to top
Profile PM
blink0k
Moderator
11
Years of Service
User Offline
Joined: 22nd Feb 2013
Location: the land of oz
Posted: 19th Nov 2020 23:39
Link
That looks great . Nice work
Back to top
Profile PM
James H
17
Years of Service
User Offline
Joined: 21st Apr 2007
Location: St Helens
Posted: 20th Nov 2020 02:15 Edited at: 20th Nov 2020 02:51
Link
Thanks man, I have made more progress. In the "color" attribute section, on line 201 change the word "normalize" to 1(just use the snippet below). Now the vertex colours are fixed Further to that I added indices while looking for clues to working out what was going on with the vertex colours...I have checked and writing in the indices has zero effect on the vertex colour issue, only the normalize flag just for the colour attribute does.

So that puts the first 3 issues to bed. As for the fourth oddity - the additional 4 bytes of unneeded empty space padding of the "position" string, it turns out that it wasn't needed in the memblock mesh at least - I have changed that value from 12 to 8 also in the below snippet. But why it is 12 with command created primitives and not 8 as well as with the mesh I loaded as an object into AppGameKit from DBP remains an oddity!



So that's it, as far as I am concerned the matters are resolved. Thanks for the help, much appreciated

Edit: There was an alignment issue with the edges(I've done this in DBP a few times so knew to check using high points on the height map edges for reference). Change the value of shift to 1 on line 403, use the attached reference height map instead of the one in my first post. In fact if you use the older snippet with this height map you will see the misalignment for yourself.
Win 7 Pro 64 bit SP1, AMD A4-5300 APU 3.4GHz, 8GB DDR3, NVidia GeForce GTX 750 1GB GDDR5, ASUS A55BM-E

Attachments

Login to view attachments
Back to top
Profile PM
blink0k
Moderator
11
Years of Service
User Offline
Joined: 22nd Feb 2013
Location: the land of oz
Posted: 20th Nov 2020 04:21
Link
I've probably done something wrong here but it doesn't appear to register shadows

Back to top
Profile PM
James H
17
Years of Service
User Offline
Joined: 21st Apr 2007
Location: St Helens
Posted: 20th Nov 2020 04:57
Link
Win 7 Pro 64 bit SP1, AMD A4-5300 APU 3.4GHz, 8GB DDR3, NVidia GeForce GTX 750 1GB GDDR5, ASUS A55BM-E
Back to top
Profile PM
blink0k
Moderator
11
Years of Service
User Offline
Joined: 22nd Feb 2013
Location: the land of oz
Posted: 20th Nov 2020 05:06 Edited at: 20th Nov 2020 05:08
Link
My bad. I see em!
Back to top
Profile PM
James H
17
Years of Service
User Offline
Joined: 21st Apr 2007
Location: St Helens
Posted: 20th Nov 2020 17:47 Edited at: 20th Nov 2020 20:12
Link
Lol, what you don't see is light I am having issues getting basic flat normals sorted out.

DBP code


what I have in AppGameKit so far...but not getting desirable results, and I have set the normalize flag on/off in the "normals" attribute, also tried different order of vertices in the subtraction code :/

(vcC exists due to vC already in use)
Only really posting this just in case someone spots something obvious

Edit: Well I did said obvious...the order was wrong and notably on that first setvector3 line I have actually mistakenly put tgt3x# instead of tgt3y# in the middle parameter!!!!!!

So the full code thus far includes the unneeded indices(so far), facet normals and some height based vertex colours in a basic manner
Win 7 Pro 64 bit SP1, AMD A4-5300 APU 3.4GHz, 8GB DDR3, NVidia GeForce GTX 750 1GB GDDR5, ASUS A55BM-E
Back to top
Profile PM
janbo
16
Years of Service
User Offline
Joined: 10th Nov 2008
Location: Germany
Posted: 27th Nov 2020 21:37 Edited at: 27th Nov 2020 21:39
Link
The Vertex Attribute strings have a NUL terminator so "position"+char(0) which is 9 and then you need to get the multiple of 4 from it which is 12
If you have the shader pack you can see how I generate meshes in the SP_MeshManipulation.agc file

Maybe you want your attribute generation a bit less hardcoded:


If you don't want to create AppGameKit vectors for this you can calculate normals like this:
Back to top
Profile PM Email Website
James H
17
Years of Service
User Offline
Joined: 21st Apr 2007
Location: St Helens
Posted: 28th Nov 2020 15:10
Link
Hi Janbo thanks for that, I am an absolute fool for not thinking of a nul terminator! Indeed I do have your shader pack...I have done little with it so far...I was more interested in seeing the performance initially. They look great...nice work. Ah yes the faster method rather than sqrt(dbp it's extremely slow), same can be said for faster distance checks(3d and 2d). Admittedly my snippets are poor!! I was initially just hashing this all out ditching being methodical out of ignorance lol. I had at one stage already used the length division but reverted back just to be sure it was not causing the issue as I was getting negative values along with lengths way way too long...all along it was my own darn typo! Obviously I would reinstate length calculation and switch from vector use in actual implementations as what I have posted was more of a case of me panning out some feesability tests which I shall touch upon momentarily.

In terms of performance the main issue lies with the speed of memory access. This is why I had asked for peek/lpoke/vertex data ptr command equivalents to Ian Molds M1U plugin for dbp...I have since had to assume vertex data command set equivalents from dbp's version is negated by the way things have otherwise been done under the hood/or the way OGLES works, so what is needed is getmemblockptr() instead(also exists in dbp) along with peek/poke commands. Looking at the function for adding heights I had compared memblock mesh access vs native set vertex position speeds. The only reason memblock route is faster is because only the y coord is changed whereas the native command alters all 3 xyz. If there where native commands separately for xyz then the native route would win out no question. I guess I figured the peek/poke route would have been much more useful for other components outside of vertex commands plus would surely have been quicker to create than providing a full compliment of commands. I suppose this is why Raven has suggested a push towards tier 2 (the other thread I mentioned), would be the only way of doing this currently. I had perhaps foolishly thought that someone would have produced and provided the community with peek/poke/ptr commands as I had noticed under tier 2 there is getmemblockptr equivalent and recalled Ian Mold had mentioned in various dbp/dgdk threads to users that they where not testing for writeable memory in terms of peek/poke...in essence I had simply thought it is simpler than it actually is.

At this stage I am less concerned about some of these things as my attention is focused around the feesability of reading from the height map to calculate smoothed normals because it would otherwise mean reading back already calculated face normals from mesh data, or storing them separately for the purpose of edge/seams of any adjacent objects/meshes including ones that haven't even been introduced to the scene on account of my focus being a rolling tile system...the work has to be offloaded across frames even with peek/poke along with the other improvements some of which you have already touched upon. This in itself is slightly complicated as the speed of the players entity has to be taken into account especially if it crosses borders diagonally in less frames than it takes to update the objects being regenerated(a 3*3 layout needs 7 buffered tiles for regeneration in the direction that the players entity resides in ie which quarter of the 3*3 layout player is within). The speed of reading from the height map for this is important as with large height maps it could be crippling enough to have to delve into coupling in a load on demand system!

I am hoping I have explained this well enough for you to understand because it has struck me that with my recent posts it might seem I am trying to be a "know it all" and I promise that I'm not! I am currently posting this from a tablet, I lost my job thanks to our wonderful government (no political comments from anyone please), I therefore am sat wrapped up in 3 layers of clothing and 2 quilts with not enough electricity to run my computer or cook my food for that matter. Our fantastic system for benefits has awarded me a grand sum of £105 for one calender month to live off...they calculate in arrears based on wages and my employer thought informing me of the loss of my job via email even though they know I had no internet access at the time and I had requested to be notified by post! Therefore for the time being my progress has been crippled in respect to actually coding...merry friggin Christmas James lol. If only I had a penny every time I've had to restart my life because of employment/benefit rules! Okay enough moaning from me, I shall be around sort of but promise to return providing I'm not dead hehehe. Seasonal Greetings to all, really appreciate the help, wonderful community as always, kindest regards
Win 7 Pro 64 bit SP1, AMD A4-5300 APU 3.4GHz, 8GB DDR3, NVidia GeForce GTX 750 1GB GDDR5, ASUS A55BM-E
Back to top
Profile PM
Back to top

Login to post a reply

Server time is: 2024-11-21 13:08:46
Your offset time is: 2024-11-21 13:08:46