Hello folks
I am a hobbyist 3D programmer who is getting on in years (73 of them!). I have messed around with 3D from the early DOS/Windows95 days until the present with its overwhelming supply of advanced 3D game engines. During this period I had a full-time job as an industrial process control software engineer. On my hobbyist side, the engines I have worked with have been PowerRender (obsolete), 3DRad (obsolete), Oddity(deprecated), Esenthel (too expensive), Unity (too heavy), and my own DirectX11 based engine. All of these have been based on C++ Windows platforms. A more detailed resume of all my projects can be found on my website www.3DRaddict.com (not updated for a while now)
Enough background history…and fast forward to the present. I decided that I would like to change to C# as my programming language, in conjunction with a lightweight graphics framework, and after some research, have settled with MonoGame.
I have found that the way to quickly get to grips with a new engine is to port the old stuff (that you know works well on previous engines) over to the new engine or framework. A project that I have been working on and off for a number of years is called “The SciTech Playroom”, and is the project I have chosen as my first MonoGame endeavour. Basically, it involves a simple room with a couple of workbenches on which the player can conduct interactive science experiments and technical demonstrations. For this to be realistic, a primary requirement is a good physics engine. I have had past experience with Nvidia PhysX, but wanted something that would integrate nicely with C#. I chose the BulletSharp MonoGame library.
As an aside, in my private capacity to help supplement my dwindling pension, I would like to run a practical interactive 3D programming course in my home town. The course will be based on this MonoGame project, whereby the students will follow its development from the ground up.
I have gathered from the threads on this forum that there is a shortage of up-to-date MonoGame 3D examples and tutorials. I would hope that, with this project and together with my course lesson preparatory work, I will be able to help out in this respect.
I commenced porting during January this year and I am pleased with the progress thus far.
Here is a video of the current stage of the project:-
The manipulation of small rigidbody objects is an important requirement for this project. The picked objects have to be manipulated smoothly (using mouse and keyboard) with no jittering.
The example video shows the small objects (coins) being picked up and dropped through the slot in the lid of the container. The container and lid each consist of a BulletSharp “CompoundShape”, comprising of a number of BulletSharp “ConvexHullShape” child shapes. These, also, are dynamic and can be picked and manipulated.
The “blocky” shadows are troubling me a bit, and I would welcome any suggestions as to how they could be simply smoothed out in MonoGame. They are currently created via a shadowmap, using a directional light source and an orthographic projection matrix.
I’ve managed to improve the “blocky” shadows by a fair amount.
I added PCF filtering to my ‘shadowmap’ shader, but with no real noticeable improvement.
The big improvement came when I increased the shadowmap size from 2048x2048 to 4096x4096, and also I reduced the depth bias value. Still “blocky”… but for this project I’m not after visual perfection, so long as the bodies interact correctly.
Here are some before and after screenshots:
I was a little dubious as to how MonoGame was going to handle the porting over of my chemistry glassware models (beakers, flasks and testtubes). I was pleasantly surprised, although I did run into a few problems:-
(1) My glass shader required a normalmap and uses tangent/binormal data in the vertex input. Monogame does not supply an in-built vertex declaration structure comprising tangent and binormal. However, with the assistance of my valuable friend (Google) I was able to find out that the MonoGame Pipeline Tool has a function “GenerateTangentFrame” which automatically calculates the tangent and binormal from the normal in your model file. BTW, all the models I am using in this project were built some time ago using 3DSMax 2010 and all exported as Wavefront .obj models.
(2) Another problem I encountered was trying to import some older version 2010 .fbx files…I had to upgrade them to version 2013 for the Pipeline Tool’s ‘Fbx Importer’ to be happy with them.
(3) Trying to import my Wavefront .obj models using the Pipeline Tool’s ‘Assimp Importer’ caused me problems. Searching through the forum threads I was able to find out that the ‘Fbx Importer’ works for Wavefront files.
Anyway, I am now importing all my models successfully with no more hiccups.
The video demonstrates the filling/pouring into/from the various pieces of glassware. At this stage I’m using some smallsize BulletSharp sphere rigidbodies to represent the liquid. At a later stage I hope to turn these into SPH particles to more accurately resemble fluid properties.
Reason given: Your post was flagged as spam: the community feels it is an advertisement, something that is overly promotional in nature instead of being useful or relevant to the topic as expected.
This was not intended at all.
My intention was purely for educational purposes as an example of applying the BulletSharp physics library to my physics-based MonoGame development project.
I am still having a problem adding a new post to this thread.
I get the message “Sorry you cannot post a link to that host.”
The new post contains a further YouTube video, so it appears that I am limited in the number of videos I can post?
Is there a way to overcome this limitation?
What if I start a new thread called “The SciTech Playroom 2” ?
The scale consists of a main body housing the weighing mechanism and the electronics. The front panel has a digital display and a tare button. A weighpan is connected to the body by spring constraint. The item to be weighed is placed on the weighpan and its mass in grams is displayed on the front panel. The tare button is used to reset the display to zero so that a specified quantity of substance can be added to a container on the weighpan. The weighscale has been calibrated for masses up to a maximum of 3000gm.
Here is a video demonstrating the above:
There is no software trickery here… I am actually using real physics via BulletSharp and its ‘Generic6DofSpringConstraint()’ function. Hooke’s Law is used to determine the mass, based on the distance that the spring is compressed. The spring has ‘Stiffness’ and ‘Damping’ constants which can be set to stabilize its operation.
In the past versions of this project I spent much of my time building basic science apparatus, with the result that actual experiments/demonstrations never saw the light of day. This has not been in vain, because now I have good supply of basic equipment with which I can start devising experiments.
During the coming weeks I will be making this equipment MonoGame/BulletSharp capable. This involves pulleys, ropes, wheels, gears, motors, batteries, magnets, stopwatches, heaters, cloth and softbodies. From the software side, I will be looking at a 3D particle system for the likes of liquids, gases, chemicals, flames, smoke and explosions (experiments sometimes go wrong!) Something I neglected in past versions was sound effects…I will be looking at adding them to this version.
The next little piece of apparatus is what I’ve called a BalanceBeam. It consists of a wooden beam with evenly marked spacings. The beam is pivoted to its support base via a BulletSharp ‘HingeConstraint’.The weights used for testing have their masses set at 500g and 250g (checked by the electronic weighscale). Quite a bit of parameter tweaking was required to get a stable and fairly accurate operation.
The main issue I experienced was that the weights started sliding down the beam as soon as it reached a certain inclination. I set the rigidbody ‘Friction’ parameter for both the beam and the weights to their maximum value of 1.0, but this had very little effect.The spacer markings had originally been painted onto the wood texture, and the weights were sliding over these markings. I solved this problem by converting the spacer markings into small ‘BoxShape’ rigidbodies, raised slightly above the surface of the rigidbody beam, thereby causing an obstruction for the sliding weight. QED!
I am very impressed with BulletSharp’s softbody rope.
However, its sparse documentation leaves much to be desired, so it took a fair bit of intensive Googling and experimentation for me to get a reasonable working piece of “rope” (in this particular project, I prefer to call it “cord”). In previous projects I have always constructed rope by means of a string of rigidbody spheres/capsules connected to each other by the particular physic engine’s “TwistConeConstraint” joints. This has invariably led to stretching and unstable performance as soon as the rope gets too long or is under load. To create a custom rope, without using a physics library, requires a degree in theoretical physics. I have neither the degree nor the time.
So this little exercise has reinforced my enthusiasm and motivation to continue with this MonoGame/BulletSharp project!
Here is a little demo video putting my “cord” to a stress test:
Now that I had what I thought was a good piece of strong cord, I decided to incorporate it into a simple pulley system. The cord would be looped around two pulleys, and then, by pulling on one end of the cord, a weight would be hauled upward.
Alas, the softbody rope was unable to grip the pulleys and it was also extremely difficult and complicated to mouse-pick a point on the rope so as to manipulate the rope. So I abandoned the softbody rope for my old faithful rigidbody rope (as described in my previous post).Surprisingly, the BulletSharp version of this rope performed far better than any of my previous versions from other physics engine libraries. I was able to get a good length of rope/cord to wind around the pulleys without ugly instabilities raising their face, when applying load. There is, however, a limit to what can be accomplished.
Here is a short video showing mouse picking of the cord…as can be seen it can be a little tricky judging the placement the cord in the groove of the pulley.
This is a video of the pulley system in action…to save time, I had previously setup the cord around the pulleys.
Imagine trying to carry out all these tasks without the help of a physics engine!
This is why I get such pleasure working in my SciTech Playroom…no complicated software algorithms/calculations to fry your brain…the physics engine takes care of all the nitty-gritty stuff for you!
I have now accomplished something that gave me an uphill battle on previous systems…a pulley drive feeding a gear train under load! The motor-driven 1:1 pulley drive powers a 3:1 gear reduction drive which powers a 2:1 contrate gear right-angled output, under the load of the heavy cube. A total reduction of 6:1 in speed, but with 6 times the original power.All of this is completely physical with all rotation transmitted via the gear teeth and gear shaft rigidbodies.
The tricky part of building this demo was accurately aligning the gears so that they would mesh smoothly with each other… any misplaced offset would result in an explosion of flying gears and pulleys! They other thing I had to figure out was how to form a closed loop of cord to wrap around the pulleys. As can be seen in the video, I accomplished this by anchoring one end of the cord (after first ensuring that the cord was positioned in the groove of one of the pulleys) and then taking the other end of the cord and wrapping it over the remaining pulley. I then joined the two ends by means of fixed contraint joint between the rigidbody end-segments of the cord. Finally, I released the anchoring, closed my eyes and activated the motor…when I opened them I was pleasantly surprised…all was operating as designed!
You will notice that I am now using a metal/reflective shader for metal brass gears and steel shafts. While I was at it I also took the liberty of chrome-plating the faucet situated on the back workbench.
I made my own environment map (for reflection) by taking six 90deg snapshots from a camera centered in the room.
I know that what I am doing is a little unusual, but I hope that it is inspiring some of you to look at the merits of using a 3D physics engine in your projects. The ‘likes’ that this project is receiving would appear to indicate so. It also gives an old man the strength to continue…
