Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[alway]

Work on the program continues; Module 2 is pretty much complete along with code for my "slice method" (oh, and if anyone knows the real name of said method, please tell me). The slice method seems to be more versatile than I first thought. After adding in code to handle exceptions which arrise when tangents are introduced, it turns out the code will even tell whether a point is on an edge line, face, or corner.

I'm currently considering combining the node generation part of module 3 and bond generation in 2, as described in the newly edited original post. And if you haven't figured out by now, I created a design document to keep track of how the code should work and copied and pasted most of it to the original post for a bit more in depth and up to date outline on my project.
At the rate I'm going, I should have a buggy, yet compilable version by early march! 

[alway]

I have now completed the node generation to the point where it should be workable. Tommorow, I plan on doing the bond generation module. I have decided to keep them seperate, as I have figured out a way to make that work well enough.

I am having increasing large gnawing doubts about some of the limitations of the program... For one, I wouldn't be suprised it it takes half an hour to generate something which looks halfway decent due to all the exponentially intensive loops in there. More worryingly are the two other limitations which place bounds on the speed at which the collisions can take place.

If a small object is moving at a speed of a few times larger than the length of the other object per frame (really fast in most cases, but far from uncommon) the node generation will become less and less adequate. This can be compensated for, but would require going back to the collision path module to add in some more stuff. Unfortunately, the compensations themselves would slow down the node generation module, and so it would be a trade-off.

The second limitation is not yet actually in place (and indeed I may solve it before it is), as it is in the physics and clean up modules. If the collisions last to long (game time, not real time here) it runs the risk of bad things happening without some way of telling it to enter the clean-up module while still keeping the physics module going. Without this, it will be unable to render a frame until the entire collision is complete. So say for example I decide to make something relatively slow like a car crash (a complexity out of the scope of this program, but a decent analogue nonetheless), without a method of telling it to clean up and render before the physics module completes, you would see the cars run into one another, but then no more renders until both cars are no longer colliding. You wouldn't see the collision itself, which is a problem.
And on some final notes, I will so be updating the main post yet again with some updated notes in node gen and slice method modules. I am also probably still on the schedule I estimated last week, although integrating the collision code with the directx code may end up bogging it down a bit longer.

[alway]

Seems "Tommorow" was longer away than I first thought. The Bond Generation Module may be just as large, if not larger than, the Node Module, and have even more Fun exceptions which will need to be handled. Or to be more specific, any concave object runs the risk of having a bond created through empty space, pretty much turning it into a convex object by the time all is said and done. To avoid this, I will have to check each bond and ensure it doesn't pass through any triangles making up the objects. It will also have to check to ensure lines which only pass tangentially to the triangles are allowed.
This will require a good deal more computing power for this stage of the simulation, but luckily it only needs to be done twice per collision (once per object).
edit: Now that I think about it though... I can use my slice method code yet again to check for lines crossing outside an object! At this rate half my program will be using that code.

[alway]

Bond module was done; physics module almost done. Only a small handful of roadblocks need a solution before I will be completely done with the modules. The two major ones of these being how to determine whether the physics part is done (in other words when the collision ends) as well as how to put humpty together again in the cleanup module. The solution I am working on for the first problem is also applicable to the second: using the velocity, position, and  possibly bonds of the nodes, I will attempt to catagorize them into chunks. These chunks will have relatively the same velocities (+ or - 1% of initial velocity difference of the 2 objects), be geographically similar (by using node density in expanding radii I think I can work out a way to determine roughly where one object ends and where another begins) and use bonds to determine where one ends and one begins. [note: sorting by position turned out to be a pain to implement, and would likely result in all sorts of problems; I ended up using bonds instead: this means there will be more and smaller chunks, but also that it should be relatively exception-free. It also involved less math, which is always good when trying to avoid bugs.]
This allows for trajectory calculations of each chunk, giving a decent picture of whether a collision is still in progress by finding whether they are set to collide.

This will help in the cleanup module since it too will divide objects into chunks. These will then be further analyzed to determine various properties (chunks consisting of 1 or 2 nodes may be culled to save processing, medium sized may be sent to a low drain system to turn back into objects, large to more a draining system which optimizes them for rendering better and culls interior nodes).

Another thing which has come to my attention is that I will probably need two different sub-modules in the cleanup module. One will be what I call a "hard cleanup" which will be more intensive and serves to prepare an object for normal, non-collision rendering.
The other is the "soft cleanup" which will just have to make the object renderable. The soft cleanup will be used during the physics collision to avoid the appearance of the program freezing when the collision takes place (due to not rendering for what could potentially be more than a few seconds, although I won't know until I test it). This will allow me to render about every x period of time while the main physics loop is being done.

All in all, what I am doing now is the most critical part of the program. The difference between something which looks like crap and looks amazing is really held in the cleanup module alone. Here's hoping I don't screw it up too badly. 

[winner]

Very nice!

[alway]

All that now remains to be done are the cleanup module, normal collision detection, and generally the portions which integrate the dynamic physics portion with the actual front end code. Yesterday I finished the physics module with a method similar to the one I planned out last week. I ended up (for only the second time while writing this program) going online and snatching up an algorithm. This one was for determining the shortest distance between 2 lines; this is very useful since it means the part of the physics module which determines when the collision is done will be much more rapid than it otherwise would be.

The tricky part that remains is the code between the dynamic collision stuff and the front end, as I said before... However, I have somewhat limited knowledge of DirectX, which may end up slowing things down considerably. Previous to this project, the most complex thing I have rendered was an unlighted cube (and even that had a bug somewhere, causing it to crash often  ). And due to my focusing solely on this project, I have not learned nearly as much as I had originally hoped I would by this point. And it really doesn't help much that I wrote the DirectX part of the code which currently exists back in December...

Oh, and I updated the percentages on the original post, since I realized I had not done so in something around a month.

edit: In addition, I will likely be putting off finishing the cleanup module until last. I get the feeling it will take me a while to come up with a satisfactory system. Unlike other parts, there really is no ideal solution which would work in every case (at least that I can think of); and indeed such a solution is probably not possible. Turning a bunch of points back into a closed 3d shape is hard, especially when said 3d shape is meant to remain convex.

[alway]

The front end is now finished enough to compile, run and show... something. Screenshot of said "something" added to original post.
It seems I still have a bit of work to do on the front end before it will be capable of rendering correctly. That rendered thing was supposed to be a cube. 

[alway]

IT LIVES. Behold my cube!
Turns out the part which was stumbling me was a matrix which failed to be passed correctly to my pixel shader. One happenstance if(FAILED()) around that line showed that... My guess is it was caused by a double declaration of the variable handle (one in my main directx class and one as a local variable). With that solved, I should now be able to render basicly any shape I want as long as it is loaded from text files containing their vertices and indices (since I am using indexed primitives). All that remains is to finish up the collision code and then the much feared cleanup module...

[alway]

Typed about 400 lines of code today, completing somewhere between a third and a half of the remaining part of the cleanup module. I would expect completion (and the start of debugging) within a week. Tommorow I should be able to finish most of the remaining stuff assuming my newly acquired Elemental: War of Magic beta doesn't suck away my weekend. In addition, I have decided to throw out the two seperate methods of making the objects rendable again in favor of more of a singular system with only a few minor tweaks between the two methods of using it.

Edit: All that now remains is to figure out what to do with the points of intersection between two objects during the process of adding said objects together into a closed, 3D shape.

[alway]

Still stuck on the last part. 
Working through algorithms dealing with 3D shapes while trying to make them absolutely fail-proof is a bit more difficult than anticipated. However, I seem to be getting closer... It seems funny how back when I started this project, I had hoped to have the coding finished by the beginning of March. It would seem that since then, the complexity and difficulty of the programming increased exponentially. Curious to see some statistics about my code, I C+P'ed it to MS word. It is now over 70 pages long, around 3000 lines, and consists of about 104,000 characters. To put that in perspective, a 1,200 word essay has ~6000 characters. Of that, the file of code containing the parts for figuring out when a collision is finished and then turning the nodes back into closed, 3d shapes is around 1000 lines and 34,000 characters.

In addition, I have decided to use this code for future programming endeavors. The main reason for this is because I am a rather lazy fellow, and I don't feel like re-typing all of the DirectX stuff (not to mention get it all working properly again). My previous restart from scratch ended up costing me a whole week of programming time I could better have spent doing something not redundant. The dynamic collision code, although I may eventually find a use for it, will probably end up disabled most of the time.