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.

Bug Reports / 'Set vertexdata uv' malfunction

Author
Message
Caleb7
8
Years of Service
User Offline
Joined: 29th Aug 2008
Location:
Posted: 17th May 2013 12:12
Hello, I've been programming a terrain system lately and have encountered some major hurtles and overcome them, but now I'm in a serious rut. The vertexdata command set is not functional when dealing with texture coordinates. In the past, I have dealt extensively with them and they worked just fine. Now that I've created the terrain mesh myself via a mesh memblock, I'm not sure this set of commands is still functional.

My symptoms:
After careful debugging, I have determined the use of 'set vertexdata uv' while specifying a texture index, zeros out every position in the entire object... permanently. I figured, "Hey if the positions are zeroed out why not just change texture coordinates first then re-position and re-normalize the geometry!" - To no avail. The changes to the vertex texture coords did stick however( only evident with get vertexdata (u/v)). My thought is that the FVF format is changed as soon as the particular command is used. When I go to re-position the geometry, it doesn't do anything. If this is indeed the problem, what is that particular FVF, the one it changes into? It probably has a diffuse value and I can't have that because I need my tangents and binormals.

Now My FVF values are as follows:
#Constant FVF_XYZ 0x002
#Constant FVF_NORMAL 0x010
#Constant FVF_TEX1 0x100
#Constant FVF_TEX2 0x200
#Constant FVF_TEX3 0x300
#Constant FVF_TEX4 0x400
#Constant FVF_TEX5 0x500
#Constant FVF_TEX6 0x600
#Constant FVF_TEX7 0x700
#Constant FVF_TEX8 0x800
#Constant FVF_DIFFUSE 0x040
#Constant FVF_SPECULAR 0x080

The particular FVF my terrain objects are made of is:
FVF_Default.format = ( FVF_xyz || FVF_NORMAL || FVF_tex4 )
FVF_Default.size = ( 4*3 + 4*3 + 4*8 )

I have the latest updates in DBPro! I know a similar error existed back in 2005 and was supposedly fixed. There's way to much code to post it all, but if you would like more, I could wrangle some up. You can assume the commands are being used correctly. The vertexdata is locked beforehand and unlocked afterwards. The vertexdata indexes are used appropriately 0 to vmax-1. I iscolated the problem from other factors. I would appreciate any fixes, workarounds, or advice you choose to offer.

Thanks,
Caleb

Randomnosity is a special influence upon man kind allowing one to think outside the usual bouderies and into a fantastic world created by oneself. Elephants don't cut it
Green Gandalf
12
Years of Service
User Offline
Joined: 3rd Jan 2005
Location: Cornwall UK
Posted: 17th May 2013 14:47 Edited at: 17th May 2013 14:48
Quote: " but if you would like more, I could wrangle some up."


More? You haven't given any code which uses the supposed offending command yet.

We need to see a short working snippet showing the problem before we can make sense of this.

That aside, there are problems with FVF formats using DIFFUSE with tangents and binormals. I've found that the only safe solution is to not mix the two. Advanced Terrain objects for example can have normal mapping if you calculate the tangents and binormals in the shader.

However, your chosen format should be quite free of that problem.

OK, before posting I've just done some quick tests. It seems possible that you need to change the lock mode. Try this simple demo. I hope it's self-explanatory. Just click the mouse to change the U data and space to exit.

There is, as you say, a problem unless you do that.

+ Code Snippet
Caleb7
8
Years of Service
User Offline
Joined: 29th Aug 2008
Location:
Posted: 18th May 2013 06:44
Quote: "More? You haven't given any code which uses the supposed offending command yet."

Haha, I guess you're right!
Here is the application of the "broken" command:

This is a part of the geometry update function:
+ Code Snippet

This is the code after I decided to somewhat separate the texturing and positioning thinking the vertices could be re-positioned after the destruction caused by 'set vertexdata uv.'


SM_Change_Vertexdata_Quad_TTex( cursor , TA , TB , TC , TD ) is a function that looks like this:

+ Code Snippet

The positioning part of the function works fine when the texturing isn't done. Also, I have already tried every lock mode; Zero wasn't the solution . The code you posted did work when the lock mode was set to zero. I disabled my terrain shader and the symptoms went away. My shader is not to blame because the texture coords assigned to it by the initial mesh memblock showed perfect results when the uv vertexdata was left alone. But I relied on DarkBasic to generate the Tangent and Binormals (I think DarkBasic does that). How do I generate them inside the shader? I'm running out of TEXTURE semantics so hopefully it won't take another!

I made a replica function for setting texturecoord vertexdata but put in debug functions to print out the texture and position data before and after the uv coordinate change. It indicated that positions are all set to zero but the texturecoords are supposedly changed correctly!

I attached a picture of the limbs being destroyed by the particular command. They should be where the rigid black gaps are.

Randomnosity is a special influence upon man kind allowing one to think outside the usual bouderies and into a fantastic world created by oneself. Elephants don't cut it

Attachments

Login to view attachments
Green Gandalf
12
Years of Service
User Offline
Joined: 3rd Jan 2005
Location: Cornwall UK
Posted: 18th May 2013 12:55
For a bug report I think we need a simpler "distilled" version of the problem.

Quote: "I disabled my terrain shader and the symptoms went away."


Interesting. When I first read your bug report I thought tangents and binormals were implicated because you were using vertex diffuse (there is a bug in the way DBPro handles those things together). However, if I've understood you correctly, you are not using vertex diffuse so that problem shouldn't arise. Yet the symptoms you describe are exactly what I'd expect to see if that's what you were doing.

For me (or anyone else) to investigate this further I need a simple short runnable code snippet to work with (including shader and essential media if necessary). Few of us have time to follow through a heirarchy of function calls, UDTs, etc, so please try to keep those to a minimum. I've done similar things myself without experiencing the problems you describe so a complete example is essential. I'll then take a closer look.
Caleb7
8
Years of Service
User Offline
Joined: 29th Aug 2008
Location:
Posted: 21st May 2013 09:46
You are correct! I am not using vertex diffuse or even specular. I'll make a simple program that exhibits the issue along with a shader. It's finals week though so I'm gonna be a little tied up for some time. Also, I will further examine my code to make sure there is no other function hidden in the labyrinths trying to write diffuse color or something.

Randomnosity is a special influence upon man kind allowing one to think outside the usual bouderies and into a fantastic world created by oneself. Elephants don't cut it
Green Gandalf
12
Years of Service
User Offline
Joined: 3rd Jan 2005
Location: Cornwall UK
Posted: 21st May 2013 18:36
Ok. No rush - good luck with the exams.
Caleb7
8
Years of Service
User Offline
Joined: 29th Aug 2008
Location:
Posted: 24th May 2013 06:23
Ok, I'm back. The attached program demonstrates that there is indeed a problem with Tangents and Binormals that goes beyond use of the diffuse and specular components. The bottom of the screen has four orange text buttons that can be used to observe the issue. You can see the malfunction begin as soon as the 'Apply Effect' button is clicked. The uv coords all scrunch up and scramble depending on the fvf format. As soon as you click 'Shift Texture' the positions of the vertices are changed so that there is no remaining visible geometry. This is all regardless of the vertex lock mode.

Randomnosity is a special influence upon man kind allowing one to think outside the usual bouderies and into a fantastic world created by oneself. Elephants don't cut it

Attachments

Login to view attachments
Green Gandalf
12
Years of Service
User Offline
Joined: 3rd Jan 2005
Location: Cornwall UK
Posted: 27th May 2013 01:31 Edited at: 27th May 2013 01:34
Thanks for that demo. Only just seen it as I've been away for a few days.

There's definitely a problem - but I'm not convinced it's the vertexdata commands causing the problem. For example, as you note, the higher stage UV values change as soon as you apply the shader (but only if you allow DBPro to recalculate tangents, etc). I've not seen that behaviour before with this FVF so I'll see if I can reduce your demo still further to isolate the cause. For example, why have seven texture stages when you only need two to show the problem?

Aside: I don't think you meant this (but it doesn't cause the problem and isn't needed anyway):

+ Code Snippet

Perhaps meshes and memblocks are implicated somehow?
Caleb7
8
Years of Service
User Offline
Joined: 29th Aug 2008
Location:
Posted: 29th May 2013 03:03 Edited at: 29th May 2013 03:05
Meshes and memblocks could be a piece of the puzzle but vertexdata isn't in the clear yet... I found another bizarre occurrence, this one without the shader. In my updated version with adjustable quantities of texture stages, you can observe that when vertexdata uv coords are altered for meshes consisting of specifically 2, 4, 5, and 6 texture coordinates, on a lock mode other than 0, the position of the corresponding vertices are also disturbed! This is only when you initialize them with a lock mode of 1 or 2. If you change them with a lock mode of 0 beforehand, you will have no problem at all. My altered version of the demo is attached. This could be a separate problem entirely but it resembles mine so much that i think it's related.

Quote: " higher stage UV values change as soon as you apply the shader"
For me, only stages 2 and 3 change significantly. Everything else reverts to how it was initially made. I even modified the shader so that those stages were no longer tangent and binormal but they where still the only indexes to change in that manor.

So with that, my guess is tangent and binormal use will consistently steal 16 bytes after the first texture coordinate(or before if you have diffuse and specular) regardless of fvf. That's why people get terrible stage 1 uv glitches with diffuse and specular. Also, I think vertexdata doesn't know how interpret this new change properly and ends up accidentally changing the position values perhaps thinking it expanded the fvf size when it didn't.

Randomnosity is a special influence upon man kind allowing one to think outside the usual bouderies and into a fantastic world created by oneself. Elephants don't cut it

Attachments

Login to view attachments
Green Gandalf
12
Years of Service
User Offline
Joined: 3rd Jan 2005
Location: Cornwall UK
Posted: 29th May 2013 12:11
Quote: "This could be a separate problem entirely but it resembles mine so much that i think it's related."


Sounds very likely.

Quote: "So with that, my guess is tangent and binormal use will consistently steal 16 bytes after the first texture coordinate"


That's what baffles me. I'm sure that in the past I've successfully used normal mapping with lightmapped objects, i.e. objects with two UV stages. The present results suggest that should fail. I need to dig out my old examples (or prepare new ones if necessary ) and see if I have this problem. It's just possible an update has broken this since my working examples were quite old.

Unfortunately I'm tied up with family for the next few days so it might be several days before I get time to study this properly - but I intend to. Give me a nudge in a week if you haven't heard.
Caleb7
8
Years of Service
User Offline
Joined: 29th Aug 2008
Location:
Posted: 13th Jul 2013 03:51
Hello, I know it's been quite some time. Life got crazy all the sudden ! I am still stumped by this one. Recently I'd decided to work on a different aspect of my program, particulate grass. Instead of doing what I've done in the past, assigning a limb to every individual blade, I wanted to speed up the fps by assigning positions to the texture coordinates so there's no need to pass as many matrices. But sure enough, despite the fact that I'm not using Binormal and Tangent data, the second I touch certain indexes with vertexdata commands geometry gets disturbed. The Fvf is the same one used in my terrain.

All in all, I know I have more troubleshooting variables to get rid of but this is starting to get a little disheartening. I already bought a book on DirectX and am looking into a healthy language change. What version of dark basic are your mentioned examples utilizing? Like you previously stated it could be a recent dis-function brought on by the last update.

Randomnosity is a special influence upon man kind allowing one to think outside the usual bouderies and into a fantastic world created by oneself. Elephants don't cut it
Green Gandalf
12
Years of Service
User Offline
Joined: 3rd Jan 2005
Location: Cornwall UK
Posted: 14th Jul 2013 02:24
Sorry, I've overlooked this. Still not sure what is causing your particular problem. Unlikely to be able to check this out in detail for a few days yet.

My earlier demos used U77RC7.
Green Gandalf
12
Years of Service
User Offline
Joined: 3rd Jan 2005
Location: Cornwall UK
Posted: 2nd Aug 2013 15:37 Edited at: 3rd Aug 2013 01:40
Finally got around to looking at this and there do indeed seem to be problems with the set vertexdata commands when tangents and binormals are used. It seems none of my earlier demos had the particular combination of commands which triggers this.

Here's the dba code I've used:

+ Code Snippet

Shader attached.

Edit I may have found a workaround. With both your latest demo and my demo, if you turn off the shader immediately before the lock vertexdata command and then turn it back on immediately after the unlock command then things seem to work correctly. I haven't checked all the UV stages though. In other words, something like this seems to work

+ Code Snippet

Perhaps you could test this?

Attachments

Login to view attachments

Login to post a reply

Server time is: 2017-04-28 11:04:20
Your offset time is: 2017-04-28 11:04:20