Building C++ supporting libraries on my small dev machine. Looking at another pass of C++/CLI work and some more thinking about motion capture options.
I’ve built zlib and bzlib2 yesterday. To get these building with VS 2017 I built them with their standard build procedures (which appeared to build 32 bit libraries) and then created visual studio 2017 projects to build the same pieces using fresh settings.
I’ve got boost, openssl, opencv and the mongodb c and c++ libraries on my list for today. The mongodb libraries are my primary target here though all of the above are of interest. This is also what is driving my CMake reading as several of these libraries use CMake for their builds.
I’m pretty interested in C++/CLI as a way to get access to C and C++ functionality from C#. Given the productivity that C# provides, access to C and C++ APIs and libraries from that environment would help quite a bit. My primary driver was access to the Win32 file ID API for some file management work, but Win32 APIs keep coming up now and again. I do need to take a look as some newer C# libraries that Malcolm suggested that may provide pre-packaged access here.
In the past, I’ve run into build issues when combining C# and C++/CLI in the same project. I expect this was setup issues so I’m now looking to take a more serious look at this.
The motion capture work will start out with OpenCV and getting my web cams running with code behind them to process the images. I’m thinking that pre-recording things and then post processing might be a good idea…using a light strobe to synchronize things could simplify time sync as well. Much to consider…
I’ve got boost, zlib and libbz2 built on boojum now. Next step will be to test the installs with a small program or two. Hoping that all went well and I have usable, native, win64 libraries available.
Once those have been checked out I’ll take another run at building the MongoDB drivers…this time on boojum rather than chaos. Boojum has a shorter history and is distinctly less cluttered than chaos so I’m hoping that this just works. Expecting less than that though…I’ll probably need to dig deeper into he CMake configs to get where I want to go. I’ll update as I move forward…now off to lunch though.
I’m realizing that once I have my star-field created, I need to figure out how best to run the mouse with a conventional mouse pointer and do hit-testing in the scene. I want to let the user click on a star and then quickly zoom in to a close-up of the star that shows its planets in some detail and any vessels that are in the system.
I’m hoping this is easy to do. It is a bit at odds with most action games, but crucial to any sort of interactive user interface created for the user.
I also hope to put up text floating near the graphical elements to add more information about them. This will include the number of ships of a given type in system, the relevant attributes of each planet and any items located on the planet. I’d like to use floating text with a transparent background and a contrasting outer edge (to ensure visibility even if something unexpected is in the background).
Cool rundown of some of the transition from stop motion to CGI. In particular I had never considered that motion blur would be an issue with the believability of stop motion sequences. Makes sense after hearing the description though.
It is pretty amazing how far and fast this technology has moved. I’m wondering what will happen now with VR/AR as they seem to have the potential to follow the same curves. Back end them through something like AWS or a direct peer to peer link and you should be able to look at building multi-person immersive environments. Add in voice recognition to replace keyboard entry. Use either multiple camera views of the participants or limb sensors and you should be able to make it amazingly real.
I find myself back again reading the documentation to OpenGL. There are so many cool things that can be done with this stuff. At this point it is a bit like a whole new API though as the programmable pipeline is new since last time I took a serious look. Much more capability, but in many ways a completely different way of making things happen.
The issues around gimbal lock with Euler angles and transformation matrices (which is the approach I’ve used in the past) are making me seriously look at quaternions again. They’re a bit of a strange hybrid, but it seems as if they offer a means to manage rotations that may have fewer sharp edges than what I’ve used in the past.
I think I may wind up buying the paper copy of the the OpenGL Superbible as it is likely to be more pleasant to flip around in than the kindle version I’ve been reading. Also suspecting that HLSL is important enough that the OpenGL Shading Language reference may be something I want on my bookshelf. Add in the OpenCL Programming Guide that I picked up when I was job searching (thought there might be some CT related opportunities and for projective reconstruction, OpenCL seems very interesting) and all sorts of stuff should be possible.
Engineering execution and creativity mixed for the best results…