Progress Report?

[rjh]

... delivering something we can play with - even if it's buggy or has broken features.

Here here (or is it "hear hear" ... not sure)

anyways ...

I agree with David ... undo shmundo - I can do without a fully functional undo (given I know its limitations). Given your previous announcement:

... I hope to be able to have something to show soon ...

I was anxious to get anything "soon" to work with. But don't think I'm un-sensitive to your plight. I too have "many" irons in the fire. To help battle my self diagnosed ADD tendencies, I made a "to-do" list that helps me focus on a few things that I've been working on. The "Jpatch" list contains 7 short films that are close to completion. Some of these I've been working on for over 3 years (on and off), so I plan to let you guys have a look at them before I subject the public to them.

Thanks for the update Sascha ... keep moving forward !

Rob

[sascha]

While I do have a number of small (well, at least compared to JPatch) other open-source projects running, most of the time is occupied by the kids - when they're finally asleep I'm often too tired to code, so I tend to fall into couch potato mode and watch one or two episodes of BSG before falling into bed
Sometimes the current JPatch problems are also simply too complex, and if I'm still in the mood for "recreational coding" I work on something more straightforward, currently this is:
* An Open-GL slideshow that displays slide shows like OS-X (i.e. with an automatic Ken-Burns effect)
* A tool to render slideshows as movies (e.g. for DVD), with full user control over Ken-Burns effects.
* Various games for small children: a puzzle games with images, ideal for learning how to use a computer-mouse, a memory-like game where you have to find the right image to a given sound (or vice versa), etc.

JPatch is the top priority, as I said, I only work on those when I don't feel fit enough to do some serious coding, so progress there is even slower. I plan to release all these things under the GPL one sourceforge too however - right now only the puzzle game and the GL-slideshow are in a usable state.

[rjh]

... other open-source projects ...

Sounds interesting ... especially the puzzle one. I did something similar with VRML quite some time ago where the player had to match a 3D shape from a ring of shapes around a shape in the middle of the ring. All the shapes had links, but only the right shape took you to the next level of more complicated shapes to match. Started with simple shapes and went to more complicated shapes and then to arrangement of shapes and finally very complicated shapes that were rotated into different positions ... Ihad quite a bit of fun with it.

Thanks for the reply ... just wanting something new to experiment with. I've recently invested in Softimage|XSI, and am (slower than I would like) learning its depths ... very powerful program. But ... I find myself going back to Jpatch for its straight-forward ease of use for what I want to do ... and besides - I have all those models rigged for animation in Jpatch! I feel compelled to do all the animations I thought of with them !

=>

Rob

[dcuny]

Anything new these days?

[dcuny]

Anything we can do to encourage progress with JPatch? I'm certainly interested in using it...

[sascha]

I should be able to find some spare time in the next couple of weeks, and I'll try to use it for JPatch development as much as possible.

I took a short JPatch break (actually I think I didn't spent much time on it since January ), but I'm back at it.

I need to fix a few issues and test, test, test. Every operation that alters the model can be broken down into two simple operations: adding and removing faces. This is what all other tools build up on - an although it sounds like a simple operation, trust me, it's now - there's an endless list of things that could go wrong, and I need this to work perfectly under all circumstances, e.g. if you delete a face with hierarchical data attached (higher-level vertices on this face have been modified), you'll want that hierarchical edits to re-appear when you undo the face deletion. You'd also like that when a deleted vertex is restored via undo, all morphs etc. that affect this vertex are updated too. I'm not saying it's impossible, but again, there are a lot of things that could possibly go wrong, and some actually do, so I need to track down the known issues and try to eliminate as many yet unknown issues as possible, which means writing a lot of test-code and performing a lot of tests. I think this should keep my busy for the next few days.

[John VanSickle]

I had difficulty with my undo/redo feature, until I found the right way to do it (naturally).

The details are a bit involved, but I have the process more or less spelled out here:

http://www.geocities.com/evilsnack/undo2.htm

[dcuny]

I'm looking forward to seeing progress!

[sascha]

I think the most straightforward way to implement multilevel undo/redo is the command pattern, and I'm using a variant of this since the early days of JPatch.

Basically, each (undoable) operation is encapsulated in an Edit object, which provides and undo() and a redo method. A more complex operation could be a collection of a number of atomic edits (e.g. an atomic edit could modify the position of a single vertex, a user's translate/scale/rotate operation - that affects a set of vertices - would be encapsulated as a set of such atomic vertex-edits.) This nicely fits into an MVC architecture, where the "model" (classes like vertex, edge, face, etc.) only contain state information, and the edit-objects (the controller) are responsible for manipulating the "model"-objects and also keep track of the last couple of edits to be able to undo them later. (The V in MVC is "view" and stands for objects responsible to display the model-objects and allow user-interaction, possibly with controller-objects in between.)

This usually is straightforward to implement and works quite well, the problem's I'm facing now result from introducing hierarchical editing without thinking about undo/redo. In my first version, undoing a "new face" operation would simply destroy the face, and redoing it would create a new face, but unfortunately this won't work if the face has hierarchy-vertices attached - in this case, exactly the same face with exactly the same sub-vertices has to be reconstructed upon redo. Since the way I store hierarchy vertices went has undergone a little evolution in the past, I have to re-implement undo-redo for this classes now.

[dcuny]

July... August... September... October...

Any news?

[sascha]

[pndragon]

[rjh]

=o
=>

" ... I am the walrus goog goog g'joob ... "
---John Lennon

[pndragon]

)