Hook implementation

Ideas, enhancements, feature requests and development related discussion.

Postby sascha » Sat May 27, 2006 2:54 pm

When selecting a curve-segment (with hooks on it), what's the reason for allowing to select the entire segment (without the hooks)? Right now I can't imagine one, so IMHO when cycling through curves with TAB, selecting JUST the hook segment (if there is a hook) sounds ok.

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.

When "expanding" a selection: If a segment was selected, it expands the selection to the entire curve, if a point (or more points) was selected, it expands the selection to all connected cps...
sascha
Site Admin
 
Posts: 2792
Joined: Thu May 20, 2004 9:16 am
Location: Austria

Postby Torf » Sat May 27, 2006 8:54 pm

sascha wrote:When selecting a curve-segment (with hooks on it), what's the reason for allowing to select the entire segment (without the hooks)?

The only tool left to operate on a non-hook-segment would be the peak/round-tool. I know that you're not fond of it, but IMO it comes in handy sometimes. And not being able to peak a segment (i.e. always peaking the whole point) would be a nightmare. But perhaps peaking a hook-segment could just peak the non-hook-segment it belongs too?

sascha wrote:
In which parts of the code are segment selections actually used?
When "expanding" a selection

Ah, okay. Not much to break here, though.
Torf
 
Posts: 155
Joined: Mon Nov 08, 2004 8:45 pm
Location: Germany/Konstanz

Postby Torf » Sun May 28, 2006 9:07 pm

There are some more places where JPatch behaves differently when a segment is selected:
  • Inserting a cp (only possible when a segment is selected)
  • Expanding a selection
  • Peaking/Rounding a segment
  • Segment deletion (Deleting a segment without deleting its start and end points)
  • Detaching cps (Detach only the selected curve)

Except segment deletion all of them can be made to work as expected with hook-segment selection (the peak/round tool and the detach tool would be disabled for hooks).
With segment deletion, I suggest turning any hooks on the ends of the deleted segments into normal control points.

It's funny that I never noticed that one could detach a single curve. Just by checking the references in the code I found that possibility. On the other hand, it only makes sense on points with more than two curves attached, and that something I try to avoid anyway :wink:
Torf
 
Posts: 155
Joined: Mon Nov 08, 2004 8:45 pm
Location: Germany/Konstanz

Postby sascha » Sun Jul 23, 2006 5:08 pm

Hi Torf!

I'd like to start integrating your "new hook" implementation into the main branch.
I'm about to make some serious changes to Model and ControlPoint, so I thought this is the right time :-)

Could you just give me a brief update on which edits are working with the new implementation an which are not?
If you've tracked the classes you've changed, that information would be useful too - but of cource I can run a diff on my own.

Thanks!
sascha
Site Admin
 
Posts: 2792
Joined: Thu May 20, 2004 9:16 am
Location: Austria

Postby Torf » Wed Aug 09, 2006 12:33 pm

Hi Sascha!

Sorry for the late answer, but our Internet has been broken for almost a month now and I've been on holiday, too.

Glad you're doing some work on the hooks even when I can't find the time to do so! Especially with your baby - 1000 congrats to you, the baby and the mother, btw!

Basically most edits should work with the new hooks, except all stuff involving clones. But I'm not too sure, so I'll check that later today and give you a more detailed answer tomorrow (I'm at the university right now).
Torf
 
Posts: 155
Joined: Mon Nov 08, 2004 8:45 pm
Location: Germany/Konstanz

Postby sascha » Wed Aug 09, 2006 3:07 pm

Hi Torf!

1000 congrats to you, the baby and the mother, btw!

Thanks a lot!

Basically most edits should work with the new hooks...

When examining at the ControlPoint class, I thought that it has become too bloated. It is the oldest part of JPatch (I think it's the first class I wrote, and since then a lot of new stuff has been added to it, but I rarely removed anything from it).
One example is the duplication of code (almost cut'n'paste) for all of the [get|compute|...]Reference[position|tangents|...] methods.
So I thought it's time to do some refactoring. I've started to create a new ControlPoint class, based on your modified one. It's now well documented (well, your modified one is well-documented too, I just thought to note this because it's not really self-evident for code that I write ;-) ) and nicely strucured, and about 80% shorter than the old one (although not all features are implemented yet).
Off course I'll need to adapt all the Edits as well: I'll also use your modified ones as a basis.

For the sake of loose coupling I'd also like to modify all classes in entity to be completely independent of any other packages (mainly boundary and control). The control package will need to reference entity classes, and boundary classes may reference classes of both, the control and the entity packages.
sascha
Site Admin
 
Posts: 2792
Joined: Thu May 20, 2004 9:16 am
Location: Austria

Postby Torf » Sun Aug 13, 2006 2:19 pm

sascha wrote:When examining at the ControlPoint class, I thought that it has become too bloated ... I've started to create a new ControlPoint class, based on your modified one. It's now well documented ... and nicely strucured, and about 80% shorter than the old one.

Sounds good! I was wondering about those Reference-/Nonreference-stuff, too, but hadn't the time to dig into it. About the comments: Most of the time missing comments didn't make understanding your code harder. You mostly did a good job when selecting method and variable names, and that's what really helps. Only some parts were hard to understand, because those names could not reflect the idea behind the code. Personally I force myself to comment every method I write nowadays, even if it's obvious what the method does...

I took a look at my changes, and I noticed that I had started making hooks selectable and moveable in the GUI. I'm not sure how much of these changes has been commited to SVN, though.

Some words about my commitment to the work on JPatch: Personally I'm pretty dissatisfied with the amount of time I was able to put into this project. But the last months have been very busy with all sort of RealLife(tm) stuff (good and bad), so more just wasn't possible. I'm really sorry that the new hook system is nowhere near completion. Hopefully my life will slow down a bit in the next term (starting in October). Until that I just want you guys to know that I haven't lost interest in JPatch :wink:
Torf
 
Posts: 155
Joined: Mon Nov 08, 2004 8:45 pm
Location: Germany/Konstanz

Postby pndragon » Sun Aug 13, 2006 7:53 pm

the last months have been very busy with all sort of RealLife(tm) stuff (good and bad)


To paraphrase - RealLife(tm) abhors a vacuum.

--- Jim
"We're so sorry, Uncle Albert,
But we haven't done a bloody thing all day."
--- Paul McCartney
pndragon
 
Posts: 591
Joined: Sun Dec 05, 2004 1:27 am
Location: North Carolina

Postby pndragon » Sun Aug 13, 2006 7:56 pm

Sorry... I couldn't resist.

--- Jim
"We're so sorry, Uncle Albert,
But we haven't done a bloody thing all day."
--- Paul McCartney
pndragon
 
Posts: 591
Joined: Sun Dec 05, 2004 1:27 am
Location: North Carolina

Postby sascha » Mon Aug 14, 2006 12:49 pm

I was wondering about those Reference-/Nonreference-stuff

Normally all methods return positions, tangents, etc. of the posed model (e.g. with bone transformations and morphs applied). The getReferenceXxx methods behave just if the model was in it's reference pose (all morphs and bone angles at their idle position).
This is needed for 3D procedural textures to "stick" with the model (unfortunately not supported by PovRay :evil: ).

I'm really sorry that the new hook system is nowhere near completion.

Don't worry :-)
I've to change some edits anyway, and I'll use this as an upportunity to clean up the stuff in the jpatch.control packages too.

...I haven't lost interest in JPatch

That's good to hear :wink:
The math related questions are still a mystery to me. None of them are vital - but the most interesting one would be a formula to compute the center and center-normal of a zeng-ball patch.
sascha
Site Admin
 
Posts: 2792
Joined: Thu May 20, 2004 9:16 am
Location: Austria

Postby dcuny » Mon Aug 14, 2006 5:02 pm

sascha wrote:...but the most interesting one would be a formula to compute the center and center-normal of a zeng-ball patch.
Parsing that statement just broke my Geek-O-Meter(TM). :wink:
dcuny
 
Posts: 2902
Joined: Fri May 21, 2004 6:07 am

Postby sascha » Mon Aug 14, 2006 9:07 pm

:)
Zheng-Ball patches (Control point surfaces over non-four-sided areas by A. A. Ball and J. J. Zheng) are generalizations of rectangular Bezier patches, and thus ideally suited to represent JPatch's non-four-sided patches.
I'd like to improve my subdivision code, but unfortunately have no clue about how to evaluate such a Zheng-Ball patch - so I emailed a copy of the paper to Torf.
Being able to evaluate just the center point (and the surface normal) of such a patch would be sufficient to start.
sascha
Site Admin
 
Posts: 2792
Joined: Thu May 20, 2004 9:16 am
Location: Austria

Re: evaluate the center point of Zheng Ball patch

Postby jjzheng » Fri May 08, 2009 2:09 pm

sascha wrote::)
Zheng-Ball patches (Control point surfaces over non-four-sided areas by A. A. Ball and J. J. Zheng) are generalizations of rectangular Bezier patches, and thus ideally suited to represent JPatch's non-four-sided patches.
I'd like to improve my subdivision code, but unfortunately have no clue about how to evaluate such a Zheng-Ball patch - so I emailed a copy of the paper to Torf.
Being able to evaluate just the center point (and the surface normal) of such a patch would be sufficient to start.


To evaluate the center point of Zheng Ball patch.
1. let all the auxiliary parameters be equal to evaluate the di for the center point.
2. substitute the di to ui to get the parameters for the center point.
3. substitutethe ui to the math expression for zheng ball patch to get the 3d coordinates for center point.

Jinjin
jjzheng
 
Posts: 1
Joined: Fri May 08, 2009 1:46 pm

Re: Hook implementation

Postby sascha » Thu Jun 04, 2009 7:04 pm

Oops, hello, welcome to the JPatch forum, and sorry for this late reply.

I've switched from bicubic patches to Catmull-Clark subdivision surfaces - they are pretty standard these days, and supported natively by many renderers (while I don't know any renderer that supports non-four-sided patches out of the box). Right now I can't tell wheter I'll completely abandon patches in JPatch or not, but for now the focus lies on SDS.

Anyway, thanks for your help, I appreciate it!
sascha
Site Admin
 
Posts: 2792
Joined: Thu May 20, 2004 9:16 am
Location: Austria

Previous

Return to Development

Who is online

Users browsing this forum: No registered users and 2 guests

cron