So now I am limited by the blender interface and I am going into the source. In order to do that I must understand how things are compiled for various machines, how openGL works, Python scripting, "C", C++, make , dependencies, libraries, debug, IDEs and many other things. I know all these things already. I have modded SuperTuxKart for atomic physics and learned models during that process as they relate to the characters and tracks. I learned something about the very limited AI which uses the tracks to guide them. I then worked with sauerbraten and the cube engine. That has a very strong dev interface and is designed to be developed by the casual user. I modded the characters, levels, scripts, sounds, but did not make changes to the source code as it was not necessary, except to play with the way in which the NPC act. It is a clean game and fairly solid. It is easy to mod and has many different modes of action.
With blender the system is in flux and though it is a fantastically complex and effective whole, it is still being extended and there are places where it is possible to extend the integrated capabilities. It is also possible to make symbiotic extensions that work with the capabilities to use them in new ways in the same way that shell scripts can be combined in a vast number of ways to achieve new results. In the shell I understand the action of the programs and how they are chained together with pipes.
My assumption of the overall structure of blender is separated by user interface, modifications to the list of surfaces and objects, the object lists itself, files, mechanisms that act on the lists to present images, systems interface that is different for each machine type, Mac,Win,Lin. I guess that the first step is to make sure that all dev dependencies are met for a build and establish a script that serves to build with a single command and substitute the new executable for old and do backup. This facilitates some test builds to determine if certain systems or build options will be better for my purposes. The export and import issues are also considered and how it interacts with other programs that use the exports and create the imports.
I have also studied the video processing programs that are available to convert still frames to video, with audio synchronization. I have not yet grasped the overall structure of the project, however based on past experience it should be about 2 days to be able to mod the source effectively in the areas I am interested in. It is a side step, but I need to have an easy way to integrate some of the features of molecular modeling, DNA analysis, and phoneme associations with character movements in animation. I also need to accelerate some of the functions that appear to be critical to all functions and solve a disassociated issue of incompatibility with ATI proprietary driver in the Linux Xorg. It is just a silly irritating ( to me ) single dot error in one of the interfaces, but it bugs me. I think it is a KDE4 window sizing transform (X axis) that is off by one dot on selection.
The program is overall a fantastic tool and holds promise for me to be a central element in an overall approach to physical <> virtual development.
I have done work from the first video interface which was black and white dot graphics and before that terminals and character based graphics, and even before that LED and lamp interfaces as video(In a sense). Perhaps that is just visual and not video :)
I have accelerated functions any number of times ( from CGA,VGA,SVGA,VESA,RISC video COs,SIMDs,MIMDs, and beyond) and have some tools that I can apply to the source to identify the pinching points. Valgrind is one tool and there are some more sophisticated tools of object-method analysis that I use.
I can also use my experience with ltrace, strace, objdump, xtrace, file, and other tools to characterize some of the aspects of the program.
I am considering a complete restructure immediately after I determine the process for this source to dispose of numerous sources and unused programs.
If I find that I can really spice it up and integrate it with antfarm, I may fork out the blender insides and combine it with molecular tools, DNA tools, SIMs, and frame-buffer feedback recognition using constructed scaled and rotated models to identify real images from a camera interface (or image files).
It is very possible that I will make some pinch point mods that are Linux and X86_64 specific. I am not really interested in doing mods for windows as I think it is a dying standard. I think that the goals of blender are to deal in graphical representation and there is no consideration at all that it could be used for other scientific purposes.
0 comments:
Post a Comment