Rendering "pipes"

Dec 18, 2012 at 2:40 PM

Folks,

Not a guru but have been tinkering with the template since 2008 -- this newer template is much more comprehensive -- excellent.  That said, many of the implementation nuances are beyond my knowledge level... hurts my brain.

I need to render the equivalent of "pipes" or "tubing" between non-dynamic sphere objects.  There are no explicit examples in the sample of using the primitive object.  I implented a cylinder set of physics and render templates but the object doesn't scale.  Can anyone explain how to implement a "pipe"/"tube" between spheres while maintaining the intent of QuickStart design?  As in, I don't want to force something sub-optimal wrt QS.

Likewise, instead of using path traversal techniques, is there a way to implement a physics model that treats the tubes as though they have a flow direction?  Kinda like a vacuum tube that, when objects are pushed into the tube, they just get "sucked" along?  There a lots of ways to do this but the vacuum tube concept would utilize the physics engine rather than a separate FollowPath goal.

Thanks,
Mike

Coordinator
Dec 18, 2012 at 3:02 PM
Not sure why cylinders aren't working properly, I may be able to look into that if its a bug.

As far as giving the tubes a flow direction you could make the tubes have a phantom physics object with a trigger on it that has a directional force on it. There is an example of this in the demo, the semi-transparent cube has a trigger that pushes objects upward. Triggers should work with any primitive shape.


On Dec 18, 2012, at 8:40 AM, "sdbMike" <notifications@codeplex.com> wrote:

From: sdbMike

Folks,

Not a guru but have been tinkering with the template since 2008 -- this newer template is much more comprehensive -- excellent. That said, many of the implementation nuances are beyond my knowledge level... hurts my brain.

I need to render the equivalent of "pipes" or "tubing" between non-dynamic sphere objects. There are no explicit examples in the sample of using the primitive object. I implented a cylinder set of physics and render templates but the object doesn't scale. Can anyone explain how to implement a "pipe"/"tube" between spheres while maintaining the intent of QuickStart design? As in, I don't want to force something sub-optimal wrt QS.

Likewise, instead of using path traversal techniques, is there a way to implement a physics model that treats the tubes as though they have a flow direction? Kinda like a vacuum tube that, when objects are pushed into the tube, they just get "sucked" along? There a lots of ways to do this but the vacuum tube concept would utilize the physics engine rather than a separate FollowPath goal.

Thanks,
Mike

Dec 18, 2012 at 3:18 PM

I tried modifying the definition (sorry, not at my dev box) where length, width, height, and radius were available (some for box and some for capsule) to try to make a "skinny" cylinder but no luck.  Probably something VERY basic that I'm missing.  Likewise, the "pipe" length would then adjust at run time based on the node positions.  Guaranteed I need to write a set of classes and methods to support this but wanted to know if anyone has tried this with your template.

Once again, AWESOME template!!

Coordinator
Dec 18, 2012 at 3:45 PM
If I get a chance ill try and look at cylinder shapes to make sure they work as intended. It could be a few days though, working some long hours at work. I'm glad you like the engine, it's not as complete as a commercial one, but it's been a fun hobby off and on for the last 5 years.


On Dec 18, 2012, at 9:18 AM, "sdbMike" <notifications@codeplex.com> wrote:

From: sdbMike

I tried modifying the definition (sorry, not at my dev box) where length, width, height, and radius were available (some for box and some for capsule) to try to make a "skinny" cylinder but no luck. Probably something VERY basic that I'm missing. Likewise, the "pipe" length would then adjust at run time based on the node positions. Guaranteed I need to write a set of classes and methods to support this but wanted to know if anyone has tried this with your template.

Once again, AWESOME template!!

Dec 19, 2012 at 1:31 AM

 I appreciate all the work you've done and recognize several man-years of effort...

Okay, back at my dev box.  I've added a template to the EntityTemplates.xml + cylinder asset + render + physics xml files and appropriately referenced.  Per your design, a cylinder can be readily added via a new BaseEntity + SceneManager.AddEntityByTemplateID.  These all work as advertised.  The only available runtime tweak is the BaseEntity scale factor.  The physics xml file has parameters (length, width, height, radius -- as already referenced) but these parameters are not applicable to rendering.  Likewise, if I want to resize or rescale in runtime, there is no BaseGameEntity method.  Like I said, I appreciate ALL the work you have done -- I just don't want to bastardize your pipeline trying get this to work.

There is no way to instantiate a primitive directly.  Should there be?  I'm betting you advise against this.  I assume the cleanest way is a BaseEntity method similar to your roll, yaw, and pitch methods? 

In the end, a pipe has to scale to handle the volume of connected pipes and I intend to add spheres as volume-demanding nodes during runtime -- so... pipes will need to expand/contract in diameter at runtime.  I'm okay without the runtime mods for now but being able set the pipe diameter during object creation would work for most of my conceptual sell.  Feel free to tell me to shut up at any time and to quit demanding -- like I said, tremendous work!!!

Thanks,

Mike

Coordinator
Dec 19, 2012 at 2:24 AM
I wanted a way to get vertices from a physics mesh so you could use the physics to render with, but never got around to it. There is the physics debug view that can render shapes, but it'd have to be reworked to render like a normal Model. It's been a year since I've worked on the engine but I swear I made a primitive shape renderer, it could be made to work with cylinders pretty easily I would imagine. I think that system is being used for the cubes and spheres in the demo. If it doesn't work you'd likely have to edit some code, but not much.

On Dec 18, 2012, at 7:31 PM, "sdbMike" <notifications@codeplex.com> wrote:

From: sdbMike

I appreciate all the work you've done and recognize several man-years of effort...

Okay, back at my dev box. I've added a template to the EntityTemplates.xml + cylinder asset + render + physics xml files and appropriately referenced. Per your design, a cylinder can be readily added via a new BaseEntity + SceneManager.AddEntityByTemplateID. These all work as advertised. The only available runtime tweak is the BaseEntity scale factor. The physics xml file has parameters (length, width, height, radius -- as already referenced) but these parameters are not applicable to rendering. Likewise, if I want to resize or rescale in runtime, there is no BaseGameEntity method. Like I said, I appreciate ALL the work you have done -- I just don't want to bastardize your pipeline trying get this to work.

There is no way to instantiate a primitive directly. Should there be? I'm betting you advise against this. I assume the cleanest way is a BaseEntity method similar to your roll, yaw, and pitch methods?

In the end, a pipe has to scale to handle the volume of connected pipes and I intend to add spheres as volume-demanding nodes during runtime -- so... pipes will need to expand/contract in diameter at runtime. I'm okay without the runtime mods for now but being able set the pipe diameter during object creation would work for most of my conceptual sell. Feel free to tell me to shut up at any time and to quit demanding -- like I said, tremendous work!!!

Thanks,

Mike

Coordinator
Dec 19, 2012 at 5:12 AM
Ok, I'm looking into the issue right now. Cylinder shapes are currently not supported by the engine. I'm not sure why they weren't supported, but I suspect it could be due to issues with the JigLibX Physics Engine. It's been a year since I've had time (or motivation) to work on the engine so I'm taking guesses as to why it wasn't supported. Anyway, I'm working on it, I'll let you know if I run into any issues, hopefully I can get this done quickly.

- Nic

On Tue, Dec 18, 2012 at 8:24 PM, <nfoste82@gmail.com> wrote:
I wanted a way to get vertices from a physics mesh so you could use the physics to render with, but never got around to it. There is the physics debug view that can render shapes, but it'd have to be reworked to render like a normal Model. It's been a year since I've worked on the engine but I swear I made a primitive shape renderer, it could be made to work with cylinders pretty easily I would imagine. I think that system is being used for the cubes and spheres in the demo. If it doesn't work you'd likely have to edit some code, but not much.

On Dec 18, 2012, at 7:31 PM, "sdbMike" <notifications@codeplex.com> wrote:

From: sdbMike

I appreciate all the work you've done and recognize several man-years of effort...

Okay, back at my dev box. I've added a template to the EntityTemplates.xml + cylinder asset + render + physics xml files and appropriately referenced. Per your design, a cylinder can be readily added via a new BaseEntity + SceneManager.AddEntityByTemplateID. These all work as advertised. The only available runtime tweak is the BaseEntity scale factor. The physics xml file has parameters (length, width, height, radius -- as already referenced) but these parameters are not applicable to rendering. Likewise, if I want to resize or rescale in runtime, there is no BaseGameEntity method. Like I said, I appreciate ALL the work you have done -- I just don't want to bastardize your pipeline trying get this to work.

There is no way to instantiate a primitive directly. Should there be? I'm betting you advise against this. I assume the cleanest way is a BaseEntity method similar to your roll, yaw, and pitch methods?

In the end, a pipe has to scale to handle the volume of connected pipes and I intend to add spheres as volume-demanding nodes during runtime -- so... pipes will need to expand/contract in diameter at runtime. I'm okay without the runtime mods for now but being able set the pipe diameter during object creation would work for most of my conceptual sell. Feel free to tell me to shut up at any time and to quit demanding -- like I said, tremendous work!!!

Thanks,

Mike

Read the full discussion online.

To add a post to this discussion, reply to this email (QuickStartEngine@discussions.codeplex.com)

To start a new discussion for this project, email QuickStartEngine@discussions.codeplex.com

You are receiving this email because you subscribed to this discussion on CodePlex. You can unsubscribe or change your settings on codePlex.com.

Please note: Images and attachments will be removed from emails. Any posts to this discussion will also be available online at codeplex.com


Coordinator
Dec 19, 2012 at 5:19 AM
Well, that was quick. Yea, so the reason cylinders were not implemented was because they were not supported by JigLibX, which is the physics engine used by Quickstart. Here's some more info: http://jiglibx.codeplex.com/discussions/24133

It looks like you can simulate a cylinder using a compound shape, but in your case that wouldn't help. For your pipes what you could probably do is use a capsule for the physics, and a cylinder primitive for the render model. I'm making sure that cylinder primitives for rendering are going to work properly for you. If not I'll get that hooked up as there is already code in place for rendering cylinders.

On Tue, Dec 18, 2012 at 11:12 PM, Nic Foster <nfoste82@gmail.com> wrote:
Ok, I'm looking into the issue right now. Cylinder shapes are currently not supported by the engine. I'm not sure why they weren't supported, but I suspect it could be due to issues with the JigLibX Physics Engine. It's been a year since I've had time (or motivation) to work on the engine so I'm taking guesses as to why it wasn't supported. Anyway, I'm working on it, I'll let you know if I run into any issues, hopefully I can get this done quickly.

- Nic


On Tue, Dec 18, 2012 at 8:24 PM, <nfoste82@gmail.com> wrote:
I wanted a way to get vertices from a physics mesh so you could use the physics to render with, but never got around to it. There is the physics debug view that can render shapes, but it'd have to be reworked to render like a normal Model. It's been a year since I've worked on the engine but I swear I made a primitive shape renderer, it could be made to work with cylinders pretty easily I would imagine. I think that system is being used for the cubes and spheres in the demo. If it doesn't work you'd likely have to edit some code, but not much.

On Dec 18, 2012, at 7:31 PM, "sdbMike" <notifications@codeplex.com> wrote:

From: sdbMike

I appreciate all the work you've done and recognize several man-years of effort...

Okay, back at my dev box. I've added a template to the EntityTemplates.xml + cylinder asset + render + physics xml files and appropriately referenced. Per your design, a cylinder can be readily added via a new BaseEntity + SceneManager.AddEntityByTemplateID. These all work as advertised. The only available runtime tweak is the BaseEntity scale factor. The physics xml file has parameters (length, width, height, radius -- as already referenced) but these parameters are not applicable to rendering. Likewise, if I want to resize or rescale in runtime, there is no BaseGameEntity method. Like I said, I appreciate ALL the work you have done -- I just don't want to bastardize your pipeline trying get this to work.

There is no way to instantiate a primitive directly. Should there be? I'm betting you advise against this. I assume the cleanest way is a BaseEntity method similar to your roll, yaw, and pitch methods?

In the end, a pipe has to scale to handle the volume of connected pipes and I intend to add spheres as volume-demanding nodes during runtime -- so... pipes will need to expand/contract in diameter at runtime. I'm okay without the runtime mods for now but being able set the pipe diameter during object creation would work for most of my conceptual sell. Feel free to tell me to shut up at any time and to quit demanding -- like I said, tremendous work!!!

Thanks,

Mike

Read the full discussion online.

To add a post to this discussion, reply to this email (QuickStartEngine@discussions.codeplex.com)

To start a new discussion for this project, email QuickStartEngine@discussions.codeplex.com

You are receiving this email because you subscribed to this discussion on CodePlex. You can unsubscribe or change your settings on codePlex.com.

Please note: Images and attachments will be removed from emails. Any posts to this discussion will also be available online at codeplex.com



Coordinator
Dec 19, 2012 at 6:04 AM
Ok, so I've gotten the cylinder primitive rendering, however dynamic resizing or even specifying height/width/radius for primitive render models is not yet supported. GeometricPrimitives for rendering was one of the last features I implemented, and scale parameters for them wasn't setup yet.

So, here's the plan:
1.) I will check in a minor version update, hopefully in the next day or two. The update will include a cylinder in the demo. Unrelated: I will also include a terrain visualization bug fix and performance improvement that I finished a month ago but didn't think was worth checking in on its own.
2.) I will be evaluating a new physics engine for QuickStart. The physics engine is called BEPUphysics. If it's suitable (has all the features the engine currently supports and more), then I will replace JigLibX with it. This will probably take about 10-15 hours or so, which spreads out over weeks for me, and will be overlapping the holidays and some important family matters that are coming up for me, so it could be a little while before I get this done. However, there's a chance that during the holidays I will have some more time, so you never know, it could be sooner than I'm imagining.
3.) In the same version as the new physics engine I can try and also implement sizing parameters for render primitives.

In the mean time, if you're familiar with programming in C# and you'd like a CylinderPrimitive that you can resize at runtime you could pretty easily create your own:
1.) In RenderComponent.cs find a function named LoadModelFromPrimitive. Make that function take height, width, radius parameters.
2.) Pass the dimensions from LoadModelFromPrimitive into the constructor for CylinderPrimitive.
3.) Make a new constructor for CylinderPrimitive that accepts the dimension parameters. CylinderPrimitive's parent class already accepts those parameters so you just pass them through in the constructor.
4.) You can load objects dynamically rather than from XML, or partially from XML and partially from code. I'd recommend setting up the entity and components from XML, except do not load a RenderComponent from XML. Then create a RenderComponent for the entity in code, passing your runtime dimension parameters to the rendercomponent.

Hopefully this helps.

On Tue, Dec 18, 2012 at 11:19 PM, Nic Foster <nfoste82@gmail.com> wrote:
Well, that was quick. Yea, so the reason cylinders were not implemented was because they were not supported by JigLibX, which is the physics engine used by Quickstart. Here's some more info: http://jiglibx.codeplex.com/discussions/24133

It looks like you can simulate a cylinder using a compound shape, but in your case that wouldn't help. For your pipes what you could probably do is use a capsule for the physics, and a cylinder primitive for the render model. I'm making sure that cylinder primitives for rendering are going to work properly for you. If not I'll get that hooked up as there is already code in place for rendering cylinders.


On Tue, Dec 18, 2012 at 11:12 PM, Nic Foster <nfoste82@gmail.com> wrote:
Ok, I'm looking into the issue right now. Cylinder shapes are currently not supported by the engine. I'm not sure why they weren't supported, but I suspect it could be due to issues with the JigLibX Physics Engine. It's been a year since I've had time (or motivation) to work on the engine so I'm taking guesses as to why it wasn't supported. Anyway, I'm working on it, I'll let you know if I run into any issues, hopefully I can get this done quickly.

- Nic


On Tue, Dec 18, 2012 at 8:24 PM, <nfoste82@gmail.com> wrote:
I wanted a way to get vertices from a physics mesh so you could use the physics to render with, but never got around to it. There is the physics debug view that can render shapes, but it'd have to be reworked to render like a normal Model. It's been a year since I've worked on the engine but I swear I made a primitive shape renderer, it could be made to work with cylinders pretty easily I would imagine. I think that system is being used for the cubes and spheres in the demo. If it doesn't work you'd likely have to edit some code, but not much.

On Dec 18, 2012, at 7:31 PM, "sdbMike" <notifications@codeplex.com> wrote:

From: sdbMike

I appreciate all the work you've done and recognize several man-years of effort...

Okay, back at my dev box. I've added a template to the EntityTemplates.xml + cylinder asset + render + physics xml files and appropriately referenced. Per your design, a cylinder can be readily added via a new BaseEntity + SceneManager.AddEntityByTemplateID. These all work as advertised. The only available runtime tweak is the BaseEntity scale factor. The physics xml file has parameters (length, width, height, radius -- as already referenced) but these parameters are not applicable to rendering. Likewise, if I want to resize or rescale in runtime, there is no BaseGameEntity method. Like I said, I appreciate ALL the work you have done -- I just don't want to bastardize your pipeline trying get this to work.

There is no way to instantiate a primitive directly. Should there be? I'm betting you advise against this. I assume the cleanest way is a BaseEntity method similar to your roll, yaw, and pitch methods?

In the end, a pipe has to scale to handle the volume of connected pipes and I intend to add spheres as volume-demanding nodes during runtime -- so... pipes will need to expand/contract in diameter at runtime. I'm okay without the runtime mods for now but being able set the pipe diameter during object creation would work for most of my conceptual sell. Feel free to tell me to shut up at any time and to quit demanding -- like I said, tremendous work!!!

Thanks,

Mike

Read the full discussion online.

To add a post to this discussion, reply to this email (QuickStartEngine@discussions.codeplex.com)

To start a new discussion for this project, email QuickStartEngine@discussions.codeplex.com

You are receiving this email because you subscribed to this discussion on CodePlex. You can unsubscribe or change your settings on codePlex.com.

Please note: Images and attachments will be removed from emails. Any posts to this discussion will also be available online at codeplex.com




Dec 19, 2012 at 3:07 PM

Holy smokes!!!  Thank you very much for looking into this.  I will be spending time on this during my vacation -- work won't wait my brain can't let it go.  I will try your band-aid suggestion and try to work my own temporary primitive (and primitive) solution -- I specifically switched to C# back in 2008 to take advantage of XNA rather than go the DirectX or OpenGL route.  I'll spend more time porting my 2D-rendered agent goal system (ala Matt Buckland) and back-fill if and if/when you get the chance to check in new code.  The pipes are truly a key part of the rendering but I've got so much work to do that I can get that part working later.  I'll also wrap my brain around your game messaging system -- I was holding off on fine tuning that in my goal system but I should be able to easily use what you've started.

I really appreciate what you've done and your willingness to help.  I'll try to hold off on my inevitable questions until after the festivities.  Happy Holidays! 

Cheers,
Mike

Coordinator
Dec 20, 2012 at 6:08 AM
No problem. I've uploaded a minor new version that has support for passing primitive shapes dimensions at runtime or from XML. It will require that you update any rendercomponent XML definition files that you're already using. I've added some different primitive shapes to the demo, loaded multiple ways, to show how this is done. Please note there is an issue with normal mapping on terrain if you set the engine to use "Reach" (DX9) instead of "HiDef" (DX10), this will be fixed in the next version.

Thanks,
- Nic

On Wed, Dec 19, 2012 at 9:07 AM, sdbMike <notifications@codeplex.com> wrote:

From: sdbMike

Holy smokes!!! Thank you very much for looking into this. I will be spending time on this during my vacation -- work won't wait my brain can't let it go. I will try your band-aid suggestion and try to work my own temporary primitive (and primitive) solution -- I specifically switched to C# back in 2008 to take advantage of XNA rather than go the DirectX or OpenGL route. I'll spend more time porting my 2D-rendered agent goal system (ala Matt Buckland) and back-fill if and if/when you get the chance to check in new code. The pipes are truly a key part of the rendering but I've got so much work to do that I can get that part working later. I'll also wrap my brain around your game messaging system -- I was holding off on fine tuning that in my goal system but I should be able to easily use what you've started.

I really appreciate what you've done and your willingness to help. I'll try to hold off on my inevitable questions until after the festivities. Happy Holidays!

Cheers,
Mike

Read the full discussion online.

To add a post to this discussion, reply to this email (QuickStartEngine@discussions.codeplex.com)

To start a new discussion for this project, email QuickStartEngine@discussions.codeplex.com

You are receiving this email because you subscribed to this discussion on CodePlex. You can unsubscribe or change your settings on codePlex.com.

Please note: Images and attachments will be removed from emails. Any posts to this discussion will also be available online at codeplex.com


Dec 20, 2012 at 12:23 PM

Outstanding!  I'll patch tonight and check out the mods.  I followed your steps above last night and got the cylinder rendering working, albeit neanderthal...  I did not modify the LoadDef segment of LoadEntity.  Instead, I just added a new RenderComponent as described in Scene.  I assume the xml rendercomponent is still in the Entity.Components dictionary but the runtime RenderComponent seems to override this?  In any case, it rendered correctly but only as a gray colored cylinder.  I'll see how you did it in your patch.  I'll then work on an anti-gravity dynamic object to traverse the pipes as well as sizing and coloring.

Once again, thanks a bunch!  Have a great holiday!!!

Cheers,

Mike

Dec 21, 2012 at 2:34 AM

Very nice!  Thanks for the quick update.  Your LoadPrimitives method was very helpful in cutting right to the needed methods.  I had to overload the PhysicsComponent ctor to account for a primitive's dimensions -- interesting note, the top segment of a cylinder is lighter than the rest and, no matter what I make the height, a sphere passes right through the top while aiming at the darker segment yields the standard bounce result.  I'll update RenderComponent to provide getter/setters on dimensions to accomplish my goal.  Probably sub-ideal for a real game but sufficient for my purposes because one of the key components of my demo will adjust height, diameter, opacity, and color on the fly.

Once again, THANK YOU!

Cheers,
Mike

Coordinator
Dec 21, 2012 at 4:51 AM
How are you handing physics for your cylinder? The physics engine jiglibx doesn't support cylinder physics.

On Thu, Dec 20, 2012 at 8:34 PM, sdbMike <notifications@codeplex.com> wrote:

From: sdbMike

Very nice! Thanks for the quick update. Your LoadPrimitives method was very helpful in cutting right to the needed methods. I had to overload the PhysicsComponent ctor to account for a primitive's dimensions -- interesting note, the top segment of a cylinder is lighter than the rest and, no matter what I make the height, a sphere passes right through the top while aiming at the darker segment yields the standard bounce result. I'll update RenderComponent to provide getter/setters on dimensions to accomplish my goal. Probably sub-ideal for a real game but sufficient for my purposes because one of the key components of my demo will adjust height, diameter, opacity, and color on the fly.

Once again, THANK YOU!

Cheers,
Mike

Read the full discussion online.

To add a post to this discussion, reply to this email (QuickStartEngine@discussions.codeplex.com)

To start a new discussion for this project, email QuickStartEngine@discussions.codeplex.com

You are receiving this email because you subscribed to this discussion on CodePlex. You can unsubscribe or change your settings on codePlex.com.

Please note: Images and attachments will be removed from emails. Any posts to this discussion will also be available online at codeplex.com


Dec 21, 2012 at 12:13 PM

Duh on my part... I cheated by giving it the capsule physics... which I figured would only be approximate and obviously was.  No worries, this part is not that important.  It was actually my 10-year old looking over my shoulder who noticed it and so I started to fiddle with it.  He watched me download, unzip, unblock the dlls (per the discussion board topic), and then build and run and said, "Hey, cool!  A bunch of different shapes.  Fly over there, Dad.  Okay, now shoot one!  Aw, man, they pass right through..."  So, "Okay, son, let's see if your idiot dad can add a PhysicsComponent..." 

The 10-year old really wants time on the keyboard to shoot the balls around and see them collide... he could do nothing but that and probably for hours ... just a standard boy.  In fact, you (as in <you> not me) could probably market an exceptionally simple game for that age group (and probably mine) where they make a bunch of different objects collide (see "Physi Bricks" and "Physi Nibbler" on the Windows 7 phone marketplace) -- wonder if you could get your model working on a Windows 7 phone with dumbed down graphics and physics to work on the miniscule resources... kinda tough.

Your update gave me PLENTY to work with.  I will very likely have questions over the next several weeks of how <best> to get several different physics characteristics -- not collisions, per se, but object pipe traversals -- to work but I'll try not to bug you... <much>... :) 

You are a Godsend, thanks again!  Merry Christmas!!!

Cheers,

Mike

Coordinator
Dec 21, 2012 at 3:30 PM
Glad to hear your son is excited about it, watching my dad programming as a kid is what got me excited about it. Since I was 7 I knew I wanted to program video games, and I was lucky enough to have that actually happen.

Anyhow, I purposely left physics off of those shapes so they'd be there for display purposes mostly to show scaling on primitive shapes, but other than the cylinder you should be able to apply accurate physics representations to them.

Windows 7 would require a good amount of work since I wouldn't be able to use shaders. The engine itself would be fine, but the end result would look quite a bit different I'm sure. No shadows, water that couldn't have reflections or refractions, and I'm sure systems like the particle system would need to be redone. On top of all of that it would probably have poor performance so a lot of optimization would need to be done. I would've done that work if Windows 7 was popular enough.

Merry Christmas!

- Nic

On Fri, Dec 21, 2012 at 6:13 AM, sdbMike <notifications@codeplex.com> wrote:

From: sdbMike

Duh on my part... I cheated by giving it the capsule physics... which I figured would only be approximate and obviously was. No worries, this part is not that important. It was actually my 10-year old looking over my shoulder who noticed it and so I started to fiddle with it. He watched me download, unzip, unblock the dlls (per the discussion board topic), and then build and run and said, "Hey, cool! A bunch of different shapes. Fly over there, Dad. Okay, now shoot one! Aw, man, they pass right through..." So, "Okay, son, let's see if your idiot dad can add a PhysicsComponent..."

The 10-year old really wants time on the keyboard to shoot the balls around and see them collide... he could do nothing but that and probably for hours ... just a standard boy. In fact, you (as in <you> not me) could probably market an exceptionally simple game for that age group (and probably mine) where they make a bunch of different objects collide (see "Physi Bricks" and "Physi Nibbler" on the Windows 7 phone marketplace) -- wonder if you could get your model working on a Windows 7 phone with dumbed down graphics and physics to work on the miniscule resources... kinda tough.

Your update gave me PLENTY to work with. I will very likely have questions over the next several weeks of how <best> to get several different physics characteristics -- not collisions, per se, but object pipe traversals -- to work but I'll try not to bug you... <much>... :)

You are a Godsend, thanks again! Merry Christmas!!!

Cheers,

Mike

Read the full discussion online.

To add a post to this discussion, reply to this email (QuickStartEngine@discussions.codeplex.com)

To start a new discussion for this project, email QuickStartEngine@discussions.codeplex.com

You are receiving this email because you subscribed to this discussion on CodePlex. You can unsubscribe or change your settings on codePlex.com.

Please note: Images and attachments will be removed from emails. Any posts to this discussion will also be available online at codeplex.com


Feb 10, 2013 at 3:54 AM
Edited Feb 10, 2013 at 3:55 AM
As always, great template!

Much fun getting pipes working. My boss is starting to get the picture... funny how 3D can do that. That said, I thought my spherical geometry math was off but I cannot get cylinders to roll and pitch in the appropriate manner to get pipes to connect to spheres. I checked the BaseEntity methods but the Matrix.CreateFromAxisAngle method doesn't yield any insight. So, when my boss says, "Hey, why don't those pipes go straight through the spheres?" I have to give him a "dunno" look.

I can't seem to upload my pics, so I'll just send my test case.

I sub'd in the following simple trig on a 10,10,10 sphericalPoint to see if my math was wrong:
            /*  Given standard xyz coordinate system with z in vertical,
             *      r = radius of spherical point (distance of xyz vector from origin)
             *      theta is angle of vector from z-axis
             *      phi is angle of vector from x-axis
             *  
             * Then,
             *      x = r sin(theta) cos(phi)
             *      y = r sin(theta) sin(phi)
             *      z = r cos(theta)
             */

            /*  For QuickStart coordinate system:
             *      theta = angle from y-axis -- so, vertical
             *      phi   = angle from x-axis -- so, from/to screen
             *      z-axis -- left-right
             *      
             *      x = r sin(theta) cos(phi)
             *      y = r * cos(theta)
             *      z = r sin(theta) sin(phi)
             */

            Vector3 pos = new Vector3(850.0f, 230.0f, 750.0f);
            float axisHeight = 20.0f;
            float axisDiam = 0.1f;

            //xyz axis reference
            Entities.PrimitiveBuilder.AddCylinder(game, pos, axisHeight, axisDiam, Color.LightBlue, 0.0f, 0.0f, 0.0f);
            Entities.PrimitiveBuilder.AddCylinder(game, pos, axisHeight, axisDiam, Color.Red, (float)(Math.PI / 2.0), 0.0f, 0.0f);
            Entities.PrimitiveBuilder.AddCylinder(game, pos, axisHeight, axisDiam, Color.Green, 0.0f, 0.0f, (float)(Math.PI / 2.0));          

            Vector3 sphericalPoint = new Vector3(10.0f, 10.0f, 10.0f);
            Vector3 trans_sphericalPoint = Vector3.Add(pos, sphericalPoint);
            Entities.PrimitiveBuilder.AddSphere(game, trans_sphericalPoint, 1.0f, Color.Blue);

            float r = Vector3.Distance(pos, trans_sphericalPoint);
            Vector3 midpoint = Vector3.Divide(sphericalPoint, 2.0f);
            Vector3 trans_midpoint = Vector3.Add(pos, midpoint);

            float roll = (float)(Math.Atan((double)(sphericalPoint.Y) / (double)(sphericalPoint.X)));
            float pitch = (float)(Math.Atan((double)(sphericalPoint.Y) / (double)(sphericalPoint.Z)));

            Entities.PrimitiveBuilder.AddCylinder(game, trans_midpoint, r, 0.5f, Color.Blue, roll, 0.0f, pitch);
and then sub'd in pur pi/4 for each and still got a bad plot.

Thoughts? Is it the matrix method or something else that I need to tweak?

OBTW, I am used to xyz coordinates with z in the vertical. Is your coordinate system an XNA thing or did you decide to work the matrix transforms that way? Just curious... I have to seriously THINK everytime I want to plot. Once again, though, excellent template!!!
Coordinator
Feb 10, 2013 at 5:29 PM
<div>I only had time to skim over your post, been extremely busy (just had a baby), but just wanted to let you know what XNA's coordinate system is by default. X = left/right, Y = up/down, and Z = to/from screen. This is pretty standard for most game engines in the last 10 years or so.</div> <div><br> </div> <div>If you're trying to rotate stuff there are methods I created for motion, I'm not sure if those methods are in the Entity class anymore or if I moved them elsewhere, but really they're just helper methods. Every method you'll need should be built into XNA's Matrix class. You should be able to find documentation about that class online, just Googling &quot;XNA Matrix class&quot; would probably find it. I'm sorry I can't be more help at the moment, I'm typing this from a phone and cannot see the pictures, so it's difficult to picture what you're trying to accomplish. Are you trying to position multiple spheres together to serve as a cylinder?</div> <div><br> <br> </div> <div>On Feb 9, 2013, at 9:54 PM, &quot;sdbMike&quot; &lt;<a href="mailto:notifications@codeplex.com">notifications@codeplex.com</a>&gt; wrote:<br> <br> </div> <blockquote type="cite"> <div> <p>From: sdbMike</p> <div id="ThreadNotificationPostBody">As always, great template! <br> <br> Much fun getting pipes working. My boss is starting to get the picture... funny how 3D can do that. That said, I thought my spherical geometry math was off but I cannot get cylinders to roll and pitch in the appropriate manner to get pipes to connect to spheres. I checked the BaseEntity methods but the Matrix.CreateFromAxisAngle method doesn't yield any insight. So, when my boss says, &quot;Hey, why don't those pipes go straight through the spheres?&quot; I have to give him a &quot;dunno&quot; look. <br> <br> So, pic1 is a basic sphere and pipe rendering... looks great. Then zoom in... pic2 shows the x-axis pipes rotate properly (other renderings show that z-axis pipes do, as well) but anything off the main axis does not rotate as planned. So, set up a basic 3D axis trial in pic3 and get the same issue. <br> <br> I sub'd in the following simple trig on the 10,10,10 sphericalPoint to see if my math was wrong:<br> <pre><code> /* Given standard xyz coordinate system with z in vertical, * r = radius of spherical point (distance of xyz vector from origin) * theta is angle of vector from z-axis * phi is angle of vector from x-axis * * Then, * x = r sin(theta) cos(phi) * y = r sin(theta) sin(phi) * z = r cos(theta) */ /* For QuickStart coordinate system: * theta = angle from y-axis -- so, vertical * phi = angle from x-axis -- so, from/to screen * z-axis -- left-right * * x = r sin(theta) cos(phi) * y = r * cos(theta) * z = r sin(theta) sin(phi) */ Vector3 pos = new Vector3(850.0f, 230.0f, 750.0f); float axisHeight = 20.0f; float axisDiam = 0.1f; //xyz axis reference Entities.PrimitiveBuilder.AddCylinder(game, pos, axisHeight, axisDiam, Color.LightBlue, 0.0f, 0.0f, 0.0f); Entities.PrimitiveBuilder.AddCylinder(game, pos, axisHeight, axisDiam, Color.Red, (float)(Math.PI / 2.0), 0.0f, 0.0f); Entities.PrimitiveBuilder.AddCylinder(game, pos, axisHeight, axisDiam, Color.Green, 0.0f, 0.0f, (float)(Math.PI / 2.0)); Vector3 sphericalPoint = new Vector3(10.0f, 10.0f, 10.0f); Vector3 trans_sphericalPoint = Vector3.Add(pos, sphericalPoint); Entities.PrimitiveBuilder.AddSphere(game, trans_sphericalPoint, 1.0f, Color.Blue); float r = Vector3.Distance(pos, trans_sphericalPoint); Vector3 midpoint = Vector3.Divide(sphericalPoint, 2.0f); Vector3 trans_midpoint = Vector3.Add(pos, midpoint); float roll = (float)(Math.Atan((double)(sphericalPoint.Y) / (double)(sphericalPoint.X))); float pitch = (float)(Math.Atan((double)(sphericalPoint.Y) / (double)(sphericalPoint.Z))); Entities.PrimitiveBuilder.AddCylinder(game, trans_midpoint, r, 0.5f, Color.Blue, roll, 0.0f, pitch);</code></pre> and then sub'd in pur pi/4 for each and still got a bad plot. <br> <br> Thoughts? Is it the matrix method or something else that I need to tweak? <br> <br> OBTW, I am used to xyz coordinates with z in the vertical. Is your coordinate system an XNA thing or did you decide to work the matrix transforms that way? Just curious... I have to seriously THINK everytime I want to plot. Once again, though, excellent template!!!<br> </div> </div> </blockquote>
Feb 10, 2013 at 8:55 PM
First, congrats on the baby!!! We need smart people to be having babies -- period -- good for the world and such. I have 4 myself but oldest is in college and youngest is in 5th grade -- long time since I've had to deal with diapers and infant-induced lack of sleep... :)

It's interesting the game engines and XNA moved to this break with convention (my background is orbital dynamics and satellite orbits where XYZ transforms to IJK coordinate systems and many, many more)... either way, it's just a matrix transform away...

With regards to Matrix, I'll have to dig in to find out why I can't seem to rotate it properly. I was unable to upload screen shots (help?) but imagine an XYZ grid with +/- 10 in all axes. Then, as you can see from the code, I plopped a sphere at 10,10,10. I then just tried to get a cylinder to connect the origin to the sphere. Regular spherical geometry and then basic trig fail to get the cylinder to roll and pitch properly. The cylinder is oh so close in the roll but at least a degree or two off in pitch. So, knowing a 10,10,10 is pure 45-degree relationships, rolling and pitching at these angles fails to connect, as well. It appears roll is almost spot on but pitch over-rotates.

I'll take a look at Matrix.

Once again, congrats on the new-born.

Cheers,
Mike
Coordinator
May 3, 2013 at 5:55 AM
Just a heads up, I've updated the engine to use a new physics engine (BEPU Physics), which does support cylinder physics. I've cleaned up various other systems as well to make them more usable. Not sure if you're still actively using the engine or in need of these changes, just sending this out in case.

Thanks,
  • Nic
May 3, 2013 at 1:47 PM
Nic,

Thanks for the update. Yes, I am still using it but have been on an 8-week heietus. I will take test drive and try to provide feedback, if necessary. As always, I appreciate all you've done.

Cheers,
Mike



Sent from Samsung tablet