Hook implementation

Ideas, enhancements, feature requests and development related discussion.

Postby Torf » Mon Mar 20, 2006 9:33 pm

When I was fixing some edits I noticed that AtomicInsertControlPoint is broken right now (official dev release). Just create a curve A->B, hook in a point and then insert a normal CP D between A and B (A->D->B). Move D around. The hook will not follow the right way.

Problem is that AtomicInsertControlPoint pays no respect to hook curves. I'm going to fix that and suggest that one must supply a further position argument to the edit. 0 means right after point A, 1 means right before B and everything in between means between the respective hooks. OK?

Another issue is that I have problems understanding a part of DefaultTool. Starting from line 923:
Code: Select all
} else if (iState == MOVE_SINGLE_POINT && cpHot.isSingle()) {

                  if (cpHot.getPrevNH() == null || cpHot.getNextNH() == null) {

                     if ((cpHot.getPrevNH() != null && (cpHot.getPrevNH().getNextAttached() == null || !cpHot.getPrevNH().getNextAttached().isHook())) || (cpHot.getNextNH().getNextAttached() == null || !cpHot.getNextNH().getNextAttached().isHook())) {

                        if (cpHot.getChildHook() == null && (cpHot.getPrevNH() == null || cpHot.getPrevNH().getChildHook() == null)) {

                           if (!cp.getNextNH().getHead().isHook() && !cp.getHead().isHook()) {

                              if (cp.getHookAt(hookPos[0]) == null) {

Could you shed some light on this? If I get it right it checks wheter the point dragged by the user should be hooked in somewhere. But what is really going on is beyond my scope :wink:

Thirdly: PatchTesselator3 seems to be a rewrite-candidate, too. At least in some parts there's a lot of hook-logic going on and I doubt simply adapting the method names will work. Haven't looked much into yet, though.
Torf
 
Posts: 155
Joined: Mon Nov 08, 2004 8:45 pm
Location: Germany/Konstanz

Postby sascha » Mon Mar 20, 2006 10:23 pm

I think in 0.4 inserting a new point on a curve that has a hook wasn't supported (and that's quite OK) - perhaps I forgot this check in 0.5 - I'll have a look...

...Could you shed some light on this?

Phew, this code is quite old, I'll try to remember:
the getClosestControlPoint call in line 891 can return a possible hook target (the overloading with the two boolean flags doesn't aid in understanding what the method does, perhaps it should be split into several methods with more descriptive names) - line 984 checks if the closes point (where the right button was clicked) is not a hook - in line 923 we are in the "else" block, so it is a hook.
cpHot is the selected point, we have to check if it's the start or end of a curve (line 924) because only start or end points can be "hooked".
Line 925 checks if the next (or prev) point is attached to a hook - it obviously doesn't make much sense to have a segment of just two points, where both points are hooked.
Line 926 checks if the segment we'd like to hook does not have a hook curve itself.
Line 927 checks if the curve segment we'd like to add the hook to is not a hook curve (I wonder if this check is necessary), and line 928 checks if the hookpos we'd like to add our hook isn't already occupied.
IIRC 925 to 927 are there to prevent recursion (I think this is the proper term for "chicken-egg-problem") problems. If you have curve A hooked to curve B, which is hooked to curve C which again is hooked to curve A you're in trouble...
In fact these recursion loops can be much larger and quite tricky to spot, so I was forced to simply prohibit hooking a curve which has hooks on it to another curve. And this way it's a simple rule but still doesn't really limit the usability of hooks.

Line 929 finally adds the new hook (the rest is done by the CompoundHook edit).

I hope this helps and is somehow accurate (as I said, it's been quite some time since I wrote this, and I maybe changed it a lot of times, so not all if() checks might be necessary...

Thirdly: PatchTesselator3 seems to be a rewrite-candidate, too.

Oh :shock: I'm afraid you're right. The PatchTesselator creates quads or triangles for final rendering, and in the case of hooks it's responsible to seamlessly connect patches with hooks to regular patches (those have a different number of vertices on their boundaries than the patches they connect too, and what it does is "snapping" the vertices to the closest ones on the neighbor patch - I think this is done in HashPatchSubdivision). I think PatchTesselator3 treats hooks specially because it needs to precompute the patch's corner normals before calling HashPatchSubdivision.

All this is not needed by the editor, it's only called when exporting in mesh format to Inyo, Pov or RIB, so you can ingore it for now. We can take a look at it once the new hooks work properly in the editor, I think the changes to PatchTesselator and HashPatchSubdivision should be quite straightforward...
sascha
Site Admin
 
Posts: 2792
Joined: Thu May 20, 2004 9:16 am
Location: Austria

Postby Torf » Wed Mar 22, 2006 6:18 pm

Thanks for your explanation, it helped a lot.

The code does now compile again (All cloning stuff and the tesselator are commented out, though). But compiling does not mean working :wink:

JPatch loads fine and everything, but as expected, doing anything that involves hooks throws an exception. I'm in for some serious debugging, I guess :D.
Hopefully I'll spot most of the errors by checking if the usages of getNextNH(), etc. are still valid with the new hook model. But that method alone is called 99 times in the whole source tree. Other problems will only be spotted by doing a lot of testing, of course.

About CVS: I didn't commit much of my changes, yet, because I'd like to have the version in CVS to be as stable as possible. Additionally there's nobody working on that branch anyways. But if you want to take a look at the code just tell me and I'll commit it.
Torf
 
Posts: 155
Joined: Mon Nov 08, 2004 8:45 pm
Location: Germany/Konstanz

Postby sascha » Wed Mar 22, 2006 7:22 pm

About CVS: I didn't commit much of my changes, yet, because I'd like to have the version in CVS to be as stable as possible. Additionally there's nobody working on that branch anyways. But if you want to take a look at the code just tell me and I'll commit it.

I actually checked it out today, out of curiosity :-)

For myself I prefer committing everything after each day (or night) I worked on the source, merely to have a backup just in case my disk dies.

If two or more developers are working on the same branch they should also commit often, just to prevent collisions - but right now this isn't the case, so don't worry - commit whenever you like :-)
sascha
Site Admin
 
Posts: 2792
Joined: Thu May 20, 2004 9:16 am
Location: Austria

Postby Torf » Wed Mar 22, 2006 10:33 pm

I gave it a second thought and commited my changes. Backup is always a nice idea, and right now the implementation of the new system is at a well-defined position - ground laying is done, now comes cleaning up.

BTW, I remember visiting your homepage some years ago. You did all those nice Escher images, right? Is there a reason your site is gone?
Torf
 
Posts: 155
Joined: Mon Nov 08, 2004 8:45 pm
Location: Germany/Konstanz

Postby sascha » Thu Mar 23, 2006 6:03 pm

Backup is always a nice idea...is there a reason your site is gone?

There is a spooky connection between these two sentences: I had no backup when the disk of the webserver died :cool: (The disks of by backup-server died some months earlier :?)
I have most of the POV-sources for the Escher images, but the old homepage (together with the image database) went to the happy hunting ground...
PS: When I saw this one I initially thought it was one of mine ;-)
sascha
Site Admin
 
Posts: 2792
Joined: Thu May 20, 2004 9:16 am
Location: Austria

Postby Torf » Sat Apr 01, 2006 8:10 pm

Yet another status report :D

I fixed two bugs which made working with hooks impossible (now you can create and remove hooks without getting NullPointerExceptions) and one which has been in JPatch before (When you're dragging a point and try to hook it in somewhere and that fails, dragging will stop).

This one is here is still present:
Image
Debugging showed that the point after the target hook as an incoming tangent of (NaN, NaN, NaN). A quick look at the code didn't show me why that is so, but this one isn't very high on my todo-list.
Actually there isn't a real todo-list at the moment: I'm incrementally trying to do normal stuff with the new system and thereby search for bugs. The next step is the patch-finder.

Since I got an exam at tuesday (last one for these vacations!) progress has been slow. I'll be on a trip to Ireland in two weeks, and I don't know if I'm able to fix the patch-finder until then, cause I'll be at my parents' home where I only got an old computer. I'll try, though :D

So I guess it'll be summer until this one is ready. Given my experience with writing code in one's spare-time, I do wonder how some open source projects accomplish such a fast release rate. More developers (or less real life :twisted:) I guess.

BTW: Your version of Escher's "Three Planes" is much nicer than mine :)
Torf
 
Posts: 155
Joined: Mon Nov 08, 2004 8:45 pm
Location: Germany/Konstanz

Postby sascha » Sat Apr 01, 2006 9:55 pm

I'll take a look at that bug if you like.

Do you think we should try to merge the two branches? I've already touched some classes that are relevant to hooks too (nothing complicated, I think at this time merging should be quite easy), but the longer we keep the branches seperate, the harder it will get. So, as far as I am concerned, we can merge them as soon as the new hooks work (more or less - a few bugs shouldn't stop us :-) )
What do you think?

PS: Ireland is a nice place, enjoy your trip!
PPS: My first version looked like this (it was one of the first images I did with POV-Ray). I later changed the background and the colors. Looks like we both ended up with the same color scheme for the pieces :cool:)
sascha
Site Admin
 
Posts: 2792
Joined: Thu May 20, 2004 9:16 am
Location: Austria

Postby Torf » Sun Apr 02, 2006 12:13 am

sascha wrote:I'll take a look at that bug if you like.

Feel free to do so. I would do it, too, just not in the near future :D

Do you think we should try to merge the two branches?

Depends. Right now the new_hook branch is not useable at all: Missing are file i/o, patch finder, tesselator and clone support. Plus the bugs I haven't spotted yet.
Of course it will get harder the longer we wait, but on the other hand I'd really like to make the new_hook branch a bit more stable/useable before merging. Unfortunately that'll take some time, though.
At least the file i/o should be in place again, don't you think (That shouldn't be too hard to do once we developed a new file format)?

The current main branch may not be bug-free, but it's pretty useable nevertheless. I think that's nice, so people can actually use the development version and do active beta-testing. If we merge now, it would take us a good amount of time to recover that state.

Therefore I suggest another approach: Instead of merging now, we could together try to get the new_hook branch stable as fast as possible, and merge after that.
Torf
 
Posts: 155
Joined: Mon Nov 08, 2004 8:45 pm
Location: Germany/Konstanz

Postby sascha » Sun Apr 02, 2006 7:45 am

That shouldn't be too hard to do once we developed a new file format

If we stick to the old format, only small changes are needed. But on the long run a new file-format will be necessary (of cource JPatch should still be able to load "old" files, or at least to covert them to the new format).

Therefore I suggest another approach: Instead of merging now, we could together try to get the new_hook branch stable as fast as possible, and merge after that.

That sounds reasonable. I've resumed work on the timeline, fixed a few bugs and added full undo/redo support. I'd like to add keyboard shortcuts, some more timeline-tools and re-enable rendering support (Inyo, POV and RenderMan) and then release it as JPatch 0.5.3 - I know that this release wouldn't fix any bugs in the modeler, but at least it would make the new animator useable. After that we could both work on the new hooks branch and integrate it into version 0.5.4 (which should have a stable modeler again) and then decide which features to add for 0.6 (IK for example :-) )...
sascha
Site Admin
 
Posts: 2792
Joined: Thu May 20, 2004 9:16 am
Location: Austria

Postby Torf » Wed May 24, 2006 6:53 pm

Hi folks!

I know this thread (and the coding behind it) has been quiet for some time now. Just want to inform you that I've not abandoned it. It's just that real life is freakin demanding at the moment (work/university/relationship/etc.). So please be patient, I've already put other projects on hold to get this one started again.

BTW: Nice to see the rest of JPatch making big progress!
Torf
 
Posts: 155
Joined: Mon Nov 08, 2004 8:45 pm
Location: Germany/Konstanz

Postby sascha » Wed May 24, 2006 8:49 pm

Hi Torf!

I think Jpatch 0.5.3 is almost ready, so I hope that I can join in soon to help you merge in the changes you've made.
sascha
Site Admin
 
Posts: 2792
Joined: Thu May 20, 2004 9:16 am
Location: Austria

Postby Torf » Sat May 27, 2006 12:26 pm

Finally I found some time and fixed some bugs. Most of the basic edits are working correctly with the new system now.

What I'm doing right now is automatic hook movement when segments are split (cp inserted) or joined (cp removed). This should ensure that the hooks keep their relative positions with respect to the original segments. Example: When you remove (not delete!) the second cp in the following situation (x - cp, o - hook):

Code: Select all
x --- o --- o --- x --- o --- x


Hooks will then be moved (internally), so that it seems they did not move:

Code: Select all
x --- o --- o ---------- o --- x


This should keep the original geometry pretty much the same (or at least change it only as much as necessary).

Same thing happens when a cp is inserted in a segment: I already changed the code so that the cp can be inserted at any position and will be correctly placed between existing hooks. Hooks are moved based on the same principle as above.
There's only one case that needs special treatment: What should happen if a cp is inserted at the exact position of a hook? That is pretty likely, for example take a segment A->B, hook in C at 0.5 (A->C->B) and then insert a cp between A and B (it will be inserted at 0.5).
JPatch 0.52 just inserts the point, leaving the hook curve (thereby damaging the model). Clearly that's not a good idea :D So I thought that in that case, one could simply convert the hook into a control point, because that is what the user probably expects anyway. Or do you have another suggestion?
Torf
 
Posts: 155
Joined: Mon Nov 08, 2004 8:45 pm
Location: Germany/Konstanz

Postby sascha » Sat May 27, 2006 12:49 pm

Most of the basic edits are working correctly with the new system now.

Cool. :D
JPatch 0.52 just inserts the point, leaving the hook curve (thereby damaging the model).

:shock:

I'm not sure what it should do: JPatch0.4 simply prohibited inserting points on segments with hooks.
If you want to change that, you could allow the user to select the hook-segment directly.
for example take a segment A->B, hook in C at 0.5

With the modification, in this case the user could either select segment A-C or C-B - if A-C was selected, inserting a point would create one between A and C, and recompute C's hook position.
sascha
Site Admin
 
Posts: 2792
Joined: Thu May 20, 2004 9:16 am
Location: Austria

Postby Torf » Sat May 27, 2006 1:50 pm

Prohibiting point insertion on segments that contain hooks sounds like a bad idea to me: If a situation arises where such an insertion was needed, a lot of work would've to be done to get around the limitation. Although one could use the knife tool to insert a point, too.

sascha wrote:If you want to change that, you could allow the user to select the hook-segment directly.

That sounds like a nice idea, but I'm not sure if this wouldn't overcomplicate things. You would either loose the possibility to select 'normal' curve segments, need another key for selecting hook segments or (when hook segments are included in the normal tab-cycle) even more tab-presses to get to the desired segment. The last possibility is IMHO the best one, as it integrates well with the current situation and is transparent to the user, too. One could use another color to highlight hook-segments, though, to make the difference clear.

In which parts of the code are segment selections actually used? From a user's point of view only point insertion and peaking/rounding segments comes to my mind. The latter should not be allowed on hook segments, of course.

After some thinking I do like the idea (it's just one step further into the make hooks almost normal control points direction, and I like that).
Torf
 
Posts: 155
Joined: Mon Nov 08, 2004 8:45 pm
Location: Germany/Konstanz

PreviousNext

Return to Development

Who is online

Users browsing this forum: No registered users and 2 guests

cron