Blitz3Ders test something for me:

Hi all!

I've written a small peice of code to buffer vertex manipulation. Its not as efficient as it could be I dont think (memory friendly, using types, but arrays could be quicker?)..

I was wondering if any of you had a few minutes to test, to report in what instances it comes out faster, and where it comes out slower. Ideally, Itd be great if you could add it to some of your own code to see where it works and where it doesnt.

If youre straight modyfying meshes without any other commands, i beleive the code is slower than blitz' ones alone- using linepick however, makes it 650% faster (someone said) using the buffering method.

So, if anyone has time, couldya test it? :) If it works, i't will no doubt will lead to a few variations until one thats efficient is written.

Thanks all!
http://www.blitzbasic.com/codearcs/codearcs.php?code=1481

Speed mode is much faster than normal mode here. However, there are no speed timings shown so I don't know by how much. :)

Also, when I move the 'spiky ball' to a certain part of the screen with the arrow keys, it speeds up greatly again.

[edit]Oh, wait - I get:
normal: 3601
speed: 324

:P

Hi big10p.

Thanks.

I must have removed the code to do the timing. Oops!!!

It could be slow at rendering because its in wireframe mode.

it would also speed up when you move it because the code linepicks at (0,0,0) which is where the mesh is, so blitz' own optimisations are probrably saying "no need to check that mesh" :)

I was also wondering if anyone had some code of their own they could test the functions with? since its "behavior in different mesh-playing-methods" im looking to find out about. :)

Nope, just me being a numpty. See edit above. :)

normal mode 3531 speed mode 305

running on a 1.7GHz Celeron, Radeon 9200 video, WinXP

[added]
funny thing though... when i ran it with debug off, it seemed to run slower... 3472 and 290... no, wait a minute... that's faster, isn't it :)

--Mike

Haha. Not bad though. The standard tests are looking good.

Yup, speed mode much faster than normal here! 1488/157

Maybe I'm misunderstanding the reason for this code, but it seems the linepicks should come after the for... next loops are done. If I was going to deform a mesh, I wouldn't do a linepick after each vertex deformation. You're performing 1000 linepicks per frame! Is that the intention?

Yes.. because there are times when you would- like I am colouring high poly meshes by vertex, using linepicks- its a kind of lighting technique.

The wait time is almost unbearable normally. The above code works well.

You can feel free to move the linepick to where *you* would use it, to see if it would help you. Thats what i'd like to test for- Circumstances when its usable.

This is why itd be great if someone could use it in their own code- In alot of cases its unusable.

I also update some meshes alot using linepick to find the nearest vertex. 20 cars per update and ONE update mesh saves me quite alot of speed.

Correct me if I am wrong please.

ms=MilliSecs()
For n=1 To 2500
	vert=Rand(0,CountVertices(sf))
	VertexCoords(sf,vert,Rand(-10,10),Rand(-10,10),Rand(-10,10))
	VertexTexCoords(sf,vert,Rand(-10,10),Rand(-10,10),Rand(-10,10))
	LinePick(0,0,0,1,1,1)
Next
ms2=MilliSecs()
normalupdate=ms2-ms

ms=MilliSecs()
For n=1 To 2500
	vert=Rand(0,CountVertices(sf))
	VertexCoords2(sf,vert,Rand(-10,10),Rand(-10,10),Rand(-10,10))
	VertexTexCoords2(sf,vert,Rand(-10,10),Rand(-10,10),Rand(-10,10))
	LinePick(0,0,0,1,1,1)
Next
updatemeshes()
ms2=MilliSecs()
Speedupdate=ms2-ms

It is any wonder the LinePick command is faster? There is no mesh to check against until you call the UpdateMeshes() Command.

If I remove the linepicks from the code entirely then the buffered system is 50% slower than straight old building from scratch.

Yeah, ive said that already- If youre not using the pick functions, the new method is slower
the mesh DOES exist- i create it as a sphere at the top :P I then randomly place all the sphere's vertices. :)

The code doesnt demo it very well, i admit, but i did rush it to check someone's point.

From what i've gathered, The only times this code will speed things up, is when you are updating multiple vertices, using pick commands inbetween.

It's an interesting point, however I do wonder if LinePick is actually returning valid information since the speed increase seems too great. Do you have a better example?

I did some tests a while ago when I wrote GEOM. Since it's a 2D in 3D setup I wanted to know if it was better to transform the vertices each frame rather then rebuild. It actually worked out better to rebuild them - Ho hum..

The line pick would return valid information to the mesh as it was at the last Updatemeshes.

WHats happening is:

When you call Linepick, the GFX card uploads the updated mesh to the card..
if youre moving vertices, then linepicking, then moving more vertices..... then your actually being very inneficient. It is sped up because if no mesh has actually been changed, the pick commands dont force the mesh to be re-uploaded :)

Ah. Point taken.

i dont really understand this cygnus, can you explain this a bit more.