mojo3d: Entity in view?

Tagged: bullet, Camera, can see, in view, physics, ProjectToViewport, viewport

This topic contains 26 replies, has 4 voices, and was last updated by DruggedBunny 12 months ago.

Viewing 15 posts - 1 through 15 (of 27 total)

1 2 →

Author

Posts

March 17, 2018 at 10:13 pm #14054

DruggedBunny

Participant

Is there a way to check if an entity is within a camera’s current view?

I’ve been using Camera.ProjectToViewport, but it gives weird results when entities are behind the camera…

https://www.youtube.com/watch?v=MTR4qYf5db4 (YouTube compression has f***ed this up completely, but you get the gist!)

I tried writing my own ‘IsInViewport’ but failed miserably, though I’m not sure if I’m even using ProjectToViewport correctly…

Notice that turning the camera all the way around (use left or right arrows) results in the * appearing again when the cube is behind the camera!

[crayon-5cb9c14fe5cdc957026403 inline="true" ]
#Import "<std>"
#Import "<mojo>"
#Import "<mojo3d>"

Using std..
Using mojo..
Using mojo3d..

Class Game Extends Window
	
	Field scene:Scene
	Field center:Model
	Field camera:Camera
	Field light:Light

	Field cube:Model
	
	Method New (title:String, width:Int, height:Int, flags:WindowFlags)
		
		Super.New (title, width, height, flags)
		
		scene = Scene.GetCurrent ()
		
		center = New Model
		
		camera = New Camera
 
			camera.Near = 0.1
		
			camera.Move (0, 0, -10)
			camera.Rotate (0, 0, 0)
		
		light = New Light
			
			light.Type = LightType.Directional
			light.CastsShadow = True
			
			light.Move (-100, 100, -100)
			light.PointAt (center)
	
		cube = Model.CreateBox (New Boxf (-1, -1, -1, 1, 1, 1), 1, 1, 1, New PbrMaterial (Color.Rnd ()))

	End

	Method ProcessInput:Void ()

		If Keyboard.KeyHit (Key.Space) Then light.CastsShadow = Not light.CastsShadow

		If Keyboard.KeyHit (Key.Escape) Then App.Terminate ()
		
		If Keyboard.KeyDown (Key.A)
			camera.Move (0.0, 0.0, 0.1)
		Endif
 
		If Keyboard.KeyDown (Key.Z)
			camera.Move (0.0, 0.0, -0.1 )
		Endif
 
		If Keyboard.KeyDown (Key.Left)
			camera.Rotate (0.0, 1.0, 0.0)
		Endif
 
		If Keyboard.KeyDown (Key.Right)
			camera.Rotate (0.0, -1.0, 0.0)
		Endif
 
		If Keyboard.KeyDown (Key.Up)
			camera.Rotate (1.0, 0.0, 0.0, True)
		Endif
 
		If Keyboard.KeyDown (Key.Down)
			camera.Rotate (-1.0, 0.0, 0.0, true)
		Endif
		
		camera.FOV = camera.FOV - (Mouse.WheelY * 5.0)
		
	End
	
	Method UpdateGame:Void ()

		ProcessInput ()
		scene.Update ()

	End
	
	Method OnRender (canvas:Canvas) Override
 
 		UpdateGame ()
		RequestRender ()
		scene.Render (canvas)
	
		Local v2:Vec2f = camera.ProjectToViewport (cube.Position)
		
		Print v2.x
'		If v2.x > 0 And v2.x <= Width And (Height - v2.y) > 0 And (Height - v2.y) <= Height
			canvas.DrawText ("*", v2.x, Height - v2.y)
'		Endif

	End

End

Function Main ()
 
	Local width:Int			= 640
	Local height:Int		= 480
	Local flags:WindowFlags	= WindowFlags.Center
	
	New AppInstance
	
	New Game ("Demo", width, height, flags)
	
	App.Run ()
		
End

100

101

102

103

104

105

106

107

108

109

110

111

112

113

114

115

116

117

[crayon-5cb9c14fe5cdc957026403 inline="true" ]

#Import "<std>"

#Import "<mojo>"

#Import "<mojo3d>"

Using std..

Using mojo..

Using mojo3d..

Class Game Extends Window

Field scene:Scene

Field center:Model

Field camera:Camera

Field light:Light

Field cube:Model

Method New (title:String, width:Int, height:Int, flags:WindowFlags)

Super.New (title, width, height, flags)

scene = Scene.GetCurrent ()

center = New Model

camera = New Camera

camera.Near = 0.1

camera.Move (0, 0, -10)

camera.Rotate (0, 0, 0)

light = New Light

light.Type = LightType.Directional

light.CastsShadow = True

light.Move (-100, 100, -100)

light.PointAt (center)

cube = Model.CreateBox (New Boxf (-1, -1, -1, 1, 1, 1), 1, 1, 1, New PbrMaterial (Color.Rnd ()))

End

Method ProcessInput:Void ()

If Keyboard.KeyHit (Key.Space) Then light.CastsShadow = Not light.CastsShadow

If Keyboard.KeyHit (Key.Escape) Then App.Terminate ()

If Keyboard.KeyDown (Key.A)

camera.Move (0.0, 0.0, 0.1)

Endif

If Keyboard.KeyDown (Key.Z)

camera.Move (0.0, 0.0, -0.1 )

Endif

If Keyboard.KeyDown (Key.Left)

camera.Rotate (0.0, 1.0, 0.0)

Endif

If Keyboard.KeyDown (Key.Right)

camera.Rotate (0.0, -1.0, 0.0)

Endif

If Keyboard.KeyDown (Key.Up)

camera.Rotate (1.0, 0.0, 0.0, True)

Endif

If Keyboard.KeyDown (Key.Down)

camera.Rotate (-1.0, 0.0, 0.0, true)

Endif

camera.FOV = camera.FOV - (Mouse.WheelY * 5.0)

End

Method UpdateGame:Void ()

ProcessInput ()

scene.Update ()

End

Method OnRender (canvas:Canvas) Override

UpdateGame ()

RequestRender ()

scene.Render (canvas)

Local v2:Vec2f = camera.ProjectToViewport (cube.Position)

Print v2.x

' If v2.x > 0 And v2.x <= Width And (Height - v2.y) > 0 And (Height - v2.y) <= Height

canvas.DrawText ("*", v2.x, Height - v2.y)

' Endif

End

Function Main ()

Local width:Int = 640

Local height:Int = 480

Local flags:WindowFlags = WindowFlags.Center

New AppInstance

New Game ("Demo", width, height, flags)

App.Run ()

End

[/crayon]

March 17, 2018 at 11:12 pm #14055

Ethernaut

Participant

Haven’t tried it, but there’s this:

Simple mojo3d view culler

March 17, 2018 at 11:27 pm #14056

DruggedBunny

Participant

Still got some weirdness at screen edges with that*, but it’ll certainly do me for now… working much better, thanks!

* I’ll wait until more official and see how it works then.

March 20, 2018 at 3:25 am #14067

Mark Sibly

Keymaster

Still got some weirdness at screen edges with that

The ‘official’ version is likely to be about the same!

Can you post a little demo-ette of the weirdness?

March 20, 2018 at 8:03 am #14069

DruggedBunny

Participant

Yeah, will do tonight.

March 20, 2018 at 1:39 pm #14072

DruggedBunny

Participant

OK, I’d deleted the code… now, on recreating it… it works perfectly, of course.

I’ve attached the code just for reference.

Few things I ran into/wished for while doing it:

1) More physics — would like to play with constraints in particular.
2) This code was just me trying to wrap all of the Collider types in a way I can fathom, but I found that Convex/Concave are unimplemented and MeshCollider is well dodgy (you referenced this being a Bullet problem in one of your mojo-vr tests). Any plans for these aspects? I got a cool-looking terrain but couldn’t drop my boxes onto it!
3) While trying to get MeshCollider working, I was struggling with obtaining the world-space size of the mesh inside a scaled-down entity, could use a way to get that if possible; also a way to visualise these things would be nice. Also, Model.Width/Height would be nice, was a struggle locating those, think I had to dig into mesh bounds boxfs or something!
4) Any chance of a pure flat-shading-mode-pretty-please?

There were more but gotta go back to work and can’t remember off-hand!

Attachments:

toybox.7z

March 21, 2018 at 9:44 pm #14085

Mark Sibly

Keymaster

OK, I’d deleted the code… now, on recreating it… it works perfectly, of course.

If you can get it to happen again, give me a shout.

More physics — would like to play with constraints in particular.

What constraint should I start with?

MeshCollider is well dodgy

God yes, I’ve spent considerable time on this and haven’t come up with any really solutions yet. If you can post some simpe examples of the problems you’re having that would help. It’s likely MeshCollider used with ‘real physics’ is always gonna be tricky and require considerable coder ‘assistance’ to get working, in the case of bullet anyway.

Fake ‘FPS physics’ still appears to be doable so it’s not a complete washout. But I was looking forward to doing some ‘real physics’ intertia-er thingy things with it so it sucks that it looks like that wont be easy.

Switching to another API would be a possiblity except that there are no real alternatives. Phys-X is the only one with similar features (and even that’s missing some of the FPS features I’d like) but that’s not open source so no go there.

world-space size of the mesh inside a scaled-down entity

Scale does not currently affect physics! I may be able to make this work eventually, but it’s way down the list…

To get ‘world bounds’ of a model, transform the mesh bounds (ie: the local bounds) by the model matrix. There should really be a AffineMat4 * Box operator in there for this but there isn’t yet (will add now) but you can use the TransformBox code above for now.

March 22, 2018 at 2:46 am #14087

DruggedBunny

Participant

Hi Mark,

Doubt I’ll see it again — the code looks like what I thought I had before, but is clearly working! That did remind me of another point, though:

5) I felt like ProjectToViewport should be returning 2D-style co-ordinates, but I’m having to invert the y result like below to correctly draw in 2D — and I imagine this would be the main use for projecting 3D-to-2D:

[crayon-5cb9c15007d8e299339111 inline="true" ]	Local pos:Vec2f = camera.ProjectToViewport (b.model.Position)
	canvas.DrawText ("X", pos.x, Height - pos.y)

[crayon-5cb9c15007d8e299339111 inline="true" ] Local pos:Vec2f = camera.ProjectToViewport (b.model.Position)

canvas.DrawText ("X", pos.x, Height - pos.y)

[/crayon]

For constraints, I’ve mostly been after fixed and ball-socket/point-to-point, going by:

http://bulletphysics.org/mediawiki-1.5.8/index.php/Constraints

The first would allow simple rocket bodies with boosters attached, and the second would allow for thrust-style orbs!

/aside: I actually was looking at a javascript demo of the double-pendulum effect yesterday, and thinking it could be used to make great random dogfighting movements:

https://nullprogram.com/double-pendulum/

(Imagine the outer ball being an enemy circling the player ‘aircraft’ at the centre! You’d probably have to position the pendulums ‘off-world’ and just use the position results to manually position a model around the player, rather than attach the pendulum to the player, but would probably look really cool if it worked!)

So, ball socket ought to at least allow a few interesting options…

One thing I’m not sure about, but seem to recall reading Bullet could do, is having constraints break apart depending on force (for more realistic bullet-hitting-wall simulations), but maybe a bit early for that.

Bullet does have built-in vehicle and ragdoll simulations, no doubt a bugger to set up, but those would be awesome to have at some point.

Wonder why Bullet is apparently so poor with the mesh stuff? Perhaps you have to supply it with ‘nicer’ meshes or something… could a QuickHull-type of thing help, or even something like whatever Maplet did to generate simplified ‘clean’ hull meshes?

Failing that, might be worth experimenting with manually-simplified collision meshes (ie. not the complex ‘real’ mesh), just to see if that works… can always specify that it’s up to the coder to produce these if it’s not automate-able (?!).

I’d swear I’ve seen Bullet doing terrain demos, but could be wrong!

I have troubling visualising scaled/translated meshes versus the visible version, but I thought what I’ve done in the attached would have worked (not sure if you class this as ‘scaled’, or if you just mean scaling the entity) — this to me reads like it’s ‘unscaled’ in the sense that the core mesh has just been amended, prior to physics being attached — note that colliders and rigidbodies are only set up in xBody.Start (), allowing for repositioning, rotating, etc prior to starting physics.

In short:

[crayon-5cb9c15007d96190542153 inline="true" ]Local car:Model = Model.Load ("asset::car_default.fbx")
	
	If car
				
		Local carbody:ModelBody = New ModelBody (car)
				
		Local car_scale:Float = 0.05
				
		car.Mesh.FitVertices (New Boxf (-car_scale * (car.Mesh.Bounds.Width * 0.5), -car_scale * (car.Mesh.Bounds.Height * 0.5), -car_scale * (car.Mesh.Bounds.Depth * 0.5), car_scale * (car.Mesh.Bounds.Width * 0.5), car_scale * (car.Mesh.Bounds.Height * 0.5), car_scale * (car.Mesh.Bounds.Depth * 0.5)))
		carbody.Move (0.0, 100.0, 10.0)
		carbody.Rotate (45, 45, 45)
				
		'carbody.Position (0.0, 0.0, 10.0)
				
		carbody.Start ()
				
	Endif

[crayon-5cb9c15007d96190542153 inline="true" ]Local car:Model = Model.Load ("asset::car_default.fbx")

If car

Local carbody:ModelBody = New ModelBody (car)

Local car_scale:Float = 0.05

car.Mesh.FitVertices (New Boxf (-car_scale * (car.Mesh.Bounds.Width * 0.5), -car_scale * (car.Mesh.Bounds.Height * 0.5), -car_scale * (car.Mesh.Bounds.Depth * 0.5), car_scale * (car.Mesh.Bounds.Width * 0.5), car_scale * (car.Mesh.Bounds.Height * 0.5), car_scale * (car.Mesh.Bounds.Depth * 0.5)))

carbody.Move (0.0, 100.0, 10.0)

carbody.Rotate (45, 45, 45)

'carbody.Position (0.0, 0.0, 10.0)

carbody.Start ()

Endif

[/crayon]

It almost does work (seems to collide at the right point in terms of model size), other than the end result doesn’t actually rotate in any way! Notice the carbody.Rotate (45, 45, 45), but the end result is it lands as if attached to an un-rotated cube. Wonder if this is related to the overall problem, ie. there’s simply some rotation not being applied or taken into account?

Attachments:

toybox-1.7z

March 22, 2018 at 8:32 pm #14102

Mark Sibly

Keymaster

I’m having to invert the y result like below to correctly draw in 2D

This issue has been fixed recently in develop branch.

Wonder why Bullet is apparently so poor with the mesh stuff?

I suspect this is actually a common problem with ‘real’ physics engines. As far as I can tell, they don’t generally work by working out a ‘collision time’ and finding an intersection point based on velocity ala blitz3d and many ‘game physics’ engines.

Instead, they seem to use an instaneous ‘am I colliding’ sort of system that generally doesn’t take into account direction of movement or anything, so they have to sort of ‘guess’ which way to move things when they are intersecting, usually based on nearest point to penetrating point etc.

To account for this and make collisions more accurate you need to perform more ‘substeps’ when updating the world which, now that I think about it, is something I haven’t even looked into yet!!!!!

I’d swear I’ve seen Bullet doing terrain demos, but could be wrong!

If you cmake the bullet repos, there are 2 demos that involve a mesh, both of which are terrain-ish and actually work pretty well. But the size of the mesh polys is quite a bit smaller than is pratical, smaller than the shapes colliding with them. I am planning to have a closer look at these demos later as it’s at least a working starting point…

Your scaling code looks right, the important thing is to *not* use Entity.Scale as physics currently ignores this. Will take a close look at your demo a bit later…

March 22, 2018 at 10:39 pm #14103

Mark Sibly

Keymaster

I’m having to invert the y result like below to correctly draw in 2D

This issue has been fixed recently in develop branch.

Wonder why Bullet is apparently so poor with the mesh stuff?

I’d swear I’ve seen Bullet doing terrain demos, but could be wrong!

Your scaling code looks right, the important thing is to *not* use Entity.Scale as physics currently ignores this. Will take a close look at your demo a bit later…

March 23, 2018 at 3:15 am #14104

DruggedBunny

Participant

That’s so weird! I remember maybe 20 years ago [18 years? Almost certainly as a result of Blitz3d collision comments] reading online about turning spheres into capsules to predict their position at a future point in time! I have assumed this would be just the norm since then! Wow.

Did notice the y-update this morning, thanks!

March 23, 2018 at 3:17 am #14105

DruggedBunny

Participant

Oh, yeah, have a look specifically at the rotation comment, just doesn’t seem to be taken into account — whether by mojo3d or Bullet I can’t tell…

March 24, 2018 at 10:23 am #14125

DruggedBunny

Participant

In my last demo (showing as toybox-1.7z), if you change the car loading code to this, you can see that the complexity of the mesh is sort of irrelevant by replacing it with a cube:

[crayon-5cb9c15015dd2398467483 inline="true" ]'		Local car:Model = Model.Load ("asset::car_default.fbx")
	
'			If car
				
				Local car:Model = Model.CreateBox (New Boxf (-50, -50, -50, 50, 50, 50), 1, 1, 1, New PbrMaterial (Color.Red))
				
				Local carbody:ModelBody = New ModelBody (car)
				
				Local car_scale:Float = 0.05
				
				car.Mesh.FitVertices (New Boxf (-car_scale * (car.Mesh.Bounds.Width * 0.5), -car_scale * (car.Mesh.Bounds.Height * 0.5), -car_scale * (car.Mesh.Bounds.Depth * 0.5), car_scale * (car.Mesh.Bounds.Width * 0.5), car_scale * (car.Mesh.Bounds.Height * 0.5), car_scale * (car.Mesh.Bounds.Depth * 0.5)))
				carbody.Move (0.0, 100.0, 10.0)
				carbody.Rotate (45, 45, 45)
				
				'carbody.Position (0.0, 0.0, 10.0)
				
				carbody.Start ()
				
'			Endif

[crayon-5cb9c15015dd2398467483 inline="true" ]' Local car:Model = Model.Load ("asset::car_default.fbx")

' If car

Local car:Model = Model.CreateBox (New Boxf (-50, -50, -50, 50, 50, 50), 1, 1, 1, New PbrMaterial (Color.Red))

Local carbody:ModelBody = New ModelBody (car)

Local car_scale:Float = 0.05

carbody.Move (0.0, 100.0, 10.0)

carbody.Rotate (45, 45, 45)

'carbody.Position (0.0, 0.0, 10.0)

carbody.Start ()

' Endif

[/crayon]

For some reason, it just doesn’t get any rotation applied during collisions…

April 21, 2018 at 3:25 pm #14446

Cole Chapman

Participant

DruggedBunny were you ever able to get ball socket/point2point constraints working?

April 21, 2018 at 9:09 pm #14447

DruggedBunny

Participant

No, they’re not in yet, just got to wait until Mark fancies playing with that stuff, hopefully soon!

Author

Posts

Viewing 15 posts - 1 through 15 (of 27 total)

1 2 →

You must be logged in to reply to this topic.

mojo3d: Entity in view?

Attachments:

Attachments:

Archives

Recent Replies

What is this?