NewsForumsCodeLogsGallerySpecsSearch

lag in camerapick()

Blitz3D Forums/Blitz3D Programming/lag in camerapick()

koekjesbaby(Posted 2004) [#1]
when i dynamically create a (pretty large) mesh it takes a while before the picked commands such as pickedX() start returning values if i use camerapick(), but i am sure that all the other pick functions would lag as well.

is there any solution for this?


Rook Zimbabwe(Posted 2004) [#2]
use mousehit(1)???

I do it this way and it seems pretty fast with about 100 entitys to scan and pick from:
;
If MouseHit(1) = True Then
	hat=CameraPick(camera,x,y)
	If hat=0 Then Goto outme
		Select empty 
			Case empty
			xx=EntityX(entity)
			zz=EntityZ(entity) 
			Default 
			pp=0
		End Select
.outme
EndIf
;



koekjesbaby(Posted 2004) [#3]
okay, that's completely not what i meant. at all.

let me try to be clearer.

if i create a surface in the main loop and it has a lot of vertices/triangles, it takes a couple of frames before the pick commands start returning their values again.


Rimmsy(Posted 2004) [#4]
a pick actually takes time depending on your world scale. Use "pickedtime()" to find out how long a pick takes to hit an entity. This is why you should use the smallest scale you possibly can.


DJWoodgate(Posted 2004) [#5]
In fact pickedtime() actually returns the fraction of length along the pickline that a pick was detected rather than the actual time, so it provides a delta reference. The docs are, ehem, somewhat misleading in this respect. For a camerapick I think the range of the pickline will be from near to far. [Edit] No, it seems to ignore the near value. So it will pick from the camera position out to the camera far value.

Anyway I think we need to see some code, because I have not noticed any lag here, though picking after modifying a large mesh may well be delayed, because as I understand it blitz has to update its internal collision data. Not that this process is explained in the docs, but thats probably just as well considering how they describe pickedtime().


Rimmsy(Posted 2004) [#6]
yeah, what he said.


koekjesbaby(Posted 2004) [#7]
sorry but i had a lag myself. try this code:
Graphics3D(640,480,0,2)
SetBuffer(BackBuffer())

c = CreateCamera()
PositionEntity(c, 0,0,-2)
CameraRange(c, .1,5)

s = CreateSphere(64)
EntityPickMode(s, 2)

s1 = CreateSphere(2)
EntityColor(s1, 255,0,0)
ScaleEntity(s1, .1,.1,.1)
s2 = CreateSphere(2)
EntityColor(s2, 0,255,0)
ScaleEntity(s2, .1,.1,.1)


While Not KeyHit(1)
	t = MilliSecs()
	CameraPick(c, MouseX(), MouseY())
	PositionEntity(s1, PickedX(), PickedY(), PickedZ())

	PositionEntity(s2, (MouseX() - 320)/640.0 * 2, -(MouseY() - 240)/480.0 * 2, -1)

	If MouseHit(1)
		DebugLog "***********************************"
		DebugLog "before creation " + (MilliSecs()-t)
		FreeEntity(s)
		s = CreateSphere(64)
		DebugLog "after creation " + (MilliSecs()-t)
		EntityPickMode(s, 2)
	
	EndIf

	RenderWorld()
	DebugLog "after renderworld " + (MilliSecs()-t)
	Flip()
Wend
End

if you click you'll see something like this in your debugwindow:
***********************************
before creation 1
after creation 11
after renderworld 14
after renderworld 173
after renderworld 2
after renderworld 5
after renderworld 2

so the frame after the rebuild of the mesh suddenly takes 173 milliseconds. why?


DJWoodgate(Posted 2004) [#8]
Because you pick the new mesh in the next frame, not the current one.


koekjesbaby(Posted 2004) [#9]
so the first pick on a newly created mesh is used to build some internal pickdata?


DJWoodgate(Posted 2004) [#10]
Yes, or a modified mesh. Picking large dynamic meshes is not recommended. That is my understanding anyway. I ran into this yonks ago and I think that was the explanation given at the time.


koekjesbaby(Posted 2004) [#11]
interesting, so there's absolutely no way to make picking on dynamic meshes faster?


LT(Posted 2004) [#12]
I think the CreateSphere line is what's slowing it down. Try this...

Graphics3D(640,480,0,2)
SetBuffer(BackBuffer())

c = CreateCamera()
PositionEntity(c, 0,0,-2)
CameraRange(c, .1,5)

s = CreateSphere(64)
EntityPickMode(s, 2)

s1 = CreateSphere(2)
EntityColor(s1, 255,0,0)
ScaleEntity(s1, .1,.1,.1)
s2 = CreateSphere(2)
EntityColor(s2, 0,255,0)
ScaleEntity(s2, .1,.1,.1)

While Not KeyHit(1)
	t = MilliSecs()
	CameraPick(c, MouseX(), MouseY())
	PositionEntity(s1, PickedX(), PickedY(), PickedZ())

	PositionEntity(s2, (MouseX() - 320)/640.0 * 2, -(MouseY() - 240)/480.0 * 2, -1)

	If MouseHit(1)
		DebugLog "***********************************"
		DebugLog "before creation " + (MilliSecs()-t)
		FreeEntity(n)
		n = CopyEntity (s)
		DebugLog "after creation " + (MilliSecs()-t)
		EntityPickMode(n, 2)
	EndIf

	RenderWorld()
	DebugLog "after renderworld " + (MilliSecs()-t)
	Flip()
Wend
End


I'm not certain if a CopyEntity command retains the pickmode, but I am assuming it doesn't.


koekjesbaby(Posted 2004) [#13]
well, the createsphere was just hypothetical, the real problem occurs when i am creating a mesh with createtriangle() and createvertex() etc. createsphere() is just a quick way to create a new mesh with loads of vertices...


LT(Posted 2004) [#14]
Yes, but it's the create function, whatever that happens to be, that's slowing it down - not the pick function or the setting of pick mode, and I thought that was what you were asking about...


Ziltch(Posted 2004) [#15]
LT is right!

If you do not create any tri's or verts your prog will not slow down! It is very fast to use the pick commands if you have nothing to pick!