IRTC Topic for April 2007: Space Settlements

General discussion about JPatch

IRTC Topic for April 2007: Space Settlements

Postby dcuny » Fri Jan 19, 2007 10:02 am

The topic hasn't yet been announced, but I'm curious as to what the upcoming capabilities of JPatch will be, in order to figure out what will be feasible for the next script.

I've already asked for some of these features, but there's no harm in repeating them. Things I'd like to see:
  • Easier Bone Selection: Using the sliders is pretty easy (although they occasionally "lock" on me. What's a pain is having to dig through the tree control to find the right bone. Being able to click on a bone, or click on a 2D "map" and have the control for that bone come up immediately would make things much easier.
  • Anchor points for locking a character to the ground had been in a prior release, and I'm hoping it's kept in. I'd like to have characters walk in the next animation.
  • A builtin FrameFlipper to preview renderered frames (with sound) would be especially helpful.
  • An OpenGL PreViz renderer (with shadows). The faster thePreViz renderer is, the better!
On the "Nice to Have, but Not Essential" list, there's
  • UV Mapping. Any sort: cube, cylinderical, whatever. I don't care - you can always work around the flaws.
  • Inverse Kinematics: Limited IK is probably better than full IK. Being able to lock a character's feet and then moving them by their hips should be doable.
  • Parent To Constraint: for attaching objects to other objects.
  • Toggle Between Edit and Choreography: Because there's always something I forgot on the model that isn't discovered until I start animating.
  • Bone movement in Morphs: I might already be there; I didn't check.
I'll probably go through my Learning Character Animation video to see what sort of essential things are missing. As I play with the curve editor more, I'm sure I'll have suggestions about that, too.

Any idea if these will be happening, or will SDS be taking up all your time for the next couple of months?
Last edited by dcuny on Tue Feb 06, 2007 11:39 pm, edited 1 time in total.
dcuny
 
Posts: 2902
Joined: Fri May 21, 2004 6:07 am

Postby sascha » Sun Jan 21, 2007 10:15 am

I'm afraid that for the round ending in April 2007 you'll have to go with what is there. I hope that the subdivision modeler is ready by then, but I doubt that the animator will be ready.
The reason is that the current animator design is a dead-end. It 's very restrictive in terms of what can be animated, has no support for a scene graph hierarchy, no support for constraints and so support for inverse kinematics.
The new design is almost finished (mostly in my head, bet there's a lot of new code that already works too).
It's based on a new concept that uses attributes. An attribute is a kind of wrapper around a primitive (e.g. a double). There are primitive attributes (encapsulating Java primitives) and compound attributes (like tuple, to represent e.g. a 3D vector). Attributes can have limits and do fire change events when their value has been changed. This way it's pretty simple to e.g. bind a textfield or a slider to an attribute - when the slider is moved, it automatically changes the attribute, and when, e.g. a controlpoint is moved in the editor, it will automatically change the value in a position textfield (if such a textfield is visible).
This way constraints (e.g. orient-like or IK constraints) can be added to attributes or sets of attributes, and every attribute can be animated by binding it to a motioncurve.
In the current version, all this requires a lot of manual coding. In the new design, most of it will "just work".

The current code is able to create a GUI component for any entity calss that uses attributes. For instancde, building an attribute-editor for the TransformNode (like this) doesn't require a single line of code!

I hope that all this will eventually speed up (and in some cases simply enable) the development of new features. Of course I can and will re-use much of the present code (I'm quite happy with the motion-curve editor for example, so I'll re-use much of it). But it's still quite a venture.
sascha
Site Admin
 
Posts: 2792
Joined: Thu May 20, 2004 9:16 am
Location: Austria

Postby dcuny » Sun Jan 21, 2007 12:47 pm

OK, I understand. :?

What I'd really like to have is a simpler way to pick bones. Something along the lines of the "shelf control", with a 2D representation, would be good. The simplest thing to do would add a "bone picker" mode to the views. That way, a new control doesn't have to be created in the GUI.

To make things as simple as possible, there would be only one view of the bones, along the z axis. That should work for bipeds. No editing of the display is possible - it uses the min/max (x.y) values of the bones to fit it to the viewport.

To handle things like feet (which might have bones aligned along the z axis), you could use the z depth to offset the bone, so (x,y,z) would map to something like (x+z, y+z), giving a parallel projection of the bones.

Bones would be displayed as lines with circles on the ends, the same as you had proposed earlier. Clicking on the circle selects the bone, because it's simpler than determining if a bone was picked.

It would probably be impossible to manipulate a hand, unless the circles were pretty small. I guess going through the bones and picking the closest hit would take care of that.

Finally, at the bottom of the screen would be three slider-like controls, one for each axis. Selecting a bone would highlight the bone, display the name of the bone above the sliders, and make those sliders active for that bone.

On mouse move events, it could scan through the list of bone points, highlight the one the mouse was closest to, and display the name. That would take some of the guesswork out of the picking process.

I haven't had an in-depth look at the JPatch code for a while. Would something like that be difficult to code? If not, I could take a crack at it myself.
dcuny
 
Posts: 2902
Joined: Fri May 21, 2004 6:07 am

Postby dcuny » Mon Jan 22, 2007 12:00 am

I've started slogging through the code. As usual, it's taken an embarassingly long time just to add something to the menu. :? So far, I've done the following:
  • Added
    Code: Select all
    <item command="shelf view"/>
  • Added to jpatch.boundary. action.xml:
    Code: Select all
       </action>
    <action name="shelf view" model="radio" group="view">
       <constructor>new ViewAction(ViewDefinition.SHELF)</constructor>
       <property key="ShortDescription" value="Shelf view"/>
       <property key="MenuText" value="Shelf view"/>
    </action>

  • Added to ViewDefinition:
    Code: Select all
    public static final int SHELF = 8;
    public static final String[] aViewName = { ... "shelf view" };

  • Added to Actions.java
    Code: Select all
    actionMap.put("shelf view", new ActionDescriptor(new ViewAction(ViewDefinition.SHELF)));
That puts the item in the menu, and attaches an action to it. Now I've got to start hacking ViewDefinition to have it display the shelf control.
Looking at ViewZoomAction as an example, it looks like you use something like:
Code: Select all
MainFrame.getInstance().getJPatchScreen().setMouseListener(...)
to create a new MouseAdaptor when an action is selected. That should keep me busy for a while. :P

Ooops... The hot water faucet on the tub just broke, and won't shut off... It looks like I'll be busy with other stuff this afternoon... :x
dcuny
 
Posts: 2902
Joined: Fri May 21, 2004 6:07 am

Postby dcuny » Mon Jan 22, 2007 11:33 am

Thanks goodness I've got family members in town that are handy with plumbing! :D

Back on topic, I'm trying to render the "shelf view" by modifying the code in Viewport2. I've added a hook in drawAnimFrame:
Code: Select all
   public void drawAnimFrame(Animation animation) {
      // shelf view?
      if (this.isShelfView()) {
         // draw the shelf view
         drawShelf(animation);
         return;
      }

      // blah blah blah...
}
Here's the code in drawShelf:
Code: Select all
   private void drawShelf(Animation animation) {

      // iterate over the animation objects
      for (AnimObject animObject:animation.getObjects()) {
         // animateable object?
         if (animObject instanceof AnimModel) {

            // get the model from the object
            Model model = animObject.getModel();
   
            // iterate over the bones
            for (Iterator it = model.getBoneSet().iterator(); it.hasNext(); ) {               
               // get the next bone
               Bone bone = (Bone) it.next();
               
               // get the reference start and end position
               Tuple3f start = bone.getReferenceStart();
               Tuple3f end = bone.getReferenceEnd();
               
               // draw a 4x4 box at the joint
               this.drawable.drawRect((start.x-2f), (int)(start.y-2f), 4, 4);
               
               // draw a line for the bone               
               this.drawable.drawLine((int)start.x, start.y, (int)end.x, (int)end.y);
            }
            
         }
      }
      
   }
This is a quick hack; I've just included it to give a general idea of what I'm doing. A couple of questions:
  • Does this drawable act like a normal canvas, or do I have to mess with a matrix?
  • How do I find the size of the drawable?
  • Is there an easy way to find out what model has been selected?
  • Does getReference return the reference position of the bone, or something else?
Thanks!
dcuny
 
Posts: 2902
Joined: Fri May 21, 2004 6:07 am

Postby sascha » Mon Jan 22, 2007 6:34 pm

Does this drawable act like a normal canvas, or do I have to mess with a matrix?

IIRC it acts like any standard canvas when drawing in 2D. You may want to use the translate and scale properties of a ViewDefinition object though.
How do I find the size of the drawable?

If you have a reference to the ViewDefinition, you can use its getWidth() and getHeight() methods. If not, simply query the height and width of the component associated with this Drawable (that's what the ViewDefinition methods above actually do - e.g. drawable.getComponent().getHeight()).
Is there an easy way to find out what model has been selected?

MainFrame.getInstance().getSelection() returns the current selection. In case of an animation, if the selection is not null, selection.getHotObject() should return the selected AnimObject.
Does getReference return the reference position of the bone, or something else?

getReferenceStart() and getReferenceEnd() return the reference start end endpoints of the bone. getStart() and getEnd() return the current (transformed) positions.
Thanks

You're welcome. I hope that the answers are correct (it's been a long time since I wrote all that) and didn't cause more confusion (like my usually outdated doc-comments do) :?

A few more notes:
* Drawable is just an abstraction for my 3D viewports (there are Java2D, OpenGL and a software rasterizer implementation). If you just want to draw 2D graphics, you can simply use any java.awt.Component. You'll might have to hack JPatchScreen though to actually display it.

* All of the code above mentioned is obsolate and has been or will be replaced by something better. The new version does, for example, only support OpenGL for drawing 3D objects, this way it's possible to optimize the rendering performance.
sascha
Site Admin
 
Posts: 2792
Joined: Thu May 20, 2004 9:16 am
Location: Austria

Postby dcuny » Mon Jan 22, 2007 10:51 pm

sascha wrote:
Does this drawable act like a normal canvas, or do I have to mess with a matrix?

IIRC it acts like any standard canvas when drawing in 2D. You may want to use the translate and scale properties of a ViewDefinition object though.
OK. I was a bit confused because what should have been a 4x4 rectangle was appearing as something much larger. I looked at the source, and didn't see any likely culprit. I just wanted to make sure I could eliminate that as a possible reason.

If you have a reference to the ViewDefinition, you can use its getWidth() and getHeight() methods. If not, simply query the height and width of the component associated with this Drawable (that's what the ViewDefinition methods above actually do - e.g. drawable.getComponent().getHeight()).
Digging into the code without some idea of how it fits together is an interesting challenge, especially when it's late at night and I'm half asleep. It's like one of opening one of those nesting dolls, and finding yet another tiny one inside. ;)

There's a lot of stuff in your application that I've never seen before. I can figure it out pretty quickly, though. It's just not how I normally think about doing things. It's a good thing, because I really don't have much experience with Java coding, and I probably do a lot of things backwards.

MainFrame.getInstance().getSelection() returns the current selection. In case of an animation, if the selection is not null, selection.getHotObject() should return the selected AnimObject.
Thanks. I wasn't sure if getSelection referred to the selected object or the group of selected items in the model. It occured to me driving to work that it had to be the first, since that wouldn't make any sense for an AnimObject. (Or maybe it would, if you could select individual bones).

getReferenceStart() and getReferenceEnd() return the reference start end endpoints of the bone. getStart() and getEnd() return the current (transformed) positions.
Excellent! The shelf view doesn't deal with displaying the transformed positions, so that should be enough.

I hope that the answers are correct (it's been a long time since I wrote all that) and didn't cause more confusion (like my usually outdated doc-comments do) :?
That's why I didn't bother looking at the documentation. On the other hand, I'm pretty scrupulous about making sure the comments in the code are correct. They've saved me a number of times, both when I've forgotten exactly what the code did, or when someone else looked at the comments and noticed it didn't match the code. :)

Drawable is just an abstraction for my 3D viewports (there are Java2D, OpenGL and a software rasterizer implementation).
Thanks, I figured that part out. I'm using the viewport because I don't want to create yet another window on the interface - I'm lazy.

All of the code above mentioned is obsolete and has been or will be replaced by something better. The new version does, for example, only support OpenGL for drawing 3D objects, this way it's possible to optimize the rendering performance.
Cool. I figure all this is going to be discarded, so I'm not that worried about it. If I can get the shelf control working, it'll give me a chance to play with some of the ideas I've been bouncing around. If it turns out to be a good idea, you wouldn't want to use my code anyway. :P
dcuny
 
Posts: 2902
Joined: Fri May 21, 2004 6:07 am

Postby sascha » Tue Jan 23, 2007 9:19 am

It's a good thing, because I really don't have much experience with Java coding, and I probably do a lot of things backwards.

I wouldn't recommend my code to serve as an example of well-written Java code, especially not this one!
Some things are pretty awkward - but it's just the outcome of constantly tweaking the code, adding new features here and there, changing a few things, etc.
The good thing about it is that I've learned a lot (both in terms of general OO design and how to create a 3D modeler and animator), so I hope that new versions will be better structured and more logical.
sascha
Site Admin
 
Posts: 2792
Joined: Thu May 20, 2004 9:16 am
Location: Austria

Postby dcuny » Tue Jan 23, 2007 11:03 am

I've been coding long enough that I can figure out what's good code and what's been hacked in to make it work. I've got years of experience doing it myself! ;)

I've got the bones rendering as a stick figure in the shelf window. I'm now coding up the mouse actions. I've decided to try using the drag actions directly on the bones - Up/Down rotates on the x axis, Left/Right rotates on the z axis. That means I don't have to render slider controls, so it's less work for me. I'm not sure how I want to do twist - maybe Shift+Drag or something. It's sort of a cheap FK without the rotate control.

One of the problems I've got is having the mouse event handler discover the size of the display. Is there a way to determine the currently selected viewport, or is there a better way to do this? I calculate the parameters when I paint the viewport in Viewport2, so I should probably cache those values with the viewport itself, instead of having the mouse recalculate them.

Edit: Never mind, MainFrame.getInstance().getJPatchScreen().getActiveViewport() should work. :roll:

Once that's done, I can get and update the bone information via getDof, getBoneRotation and setBoneRotation. That looks pretty simple.

Once I've updated the bone's rotation, how do update the viewports?

A couple things that are currently messed up:
  • The mouse handler isn't cleared properly when focus changes to another viewport.
  • The application isn't properly refreshing.
Once I've got this working, I'll probably post the source code again, so you can see if you can track these down. There are some ugly hacks in the code. :?

From the looks of it, all the parts are in place for FK - bone collision detection in 3D mode, a rotate control... It seems like it would be pretty straight forward to get FK working. I'm assuming that something that I don't know about is terribly broken, or did you just run out of time before getting sidetracked with SDS?
dcuny
 
Posts: 2902
Joined: Fri May 21, 2004 6:07 am

Postby sascha » Tue Jan 23, 2007 1:03 pm

One of the problems I've got is having the mouse event handler discover the size of the display

Well, the mouse-event originates from the component of the active viewport, so I think
((Component) mouseEvent.getSource()).getWidth() should do the trick.

Once I've updated the bone's rotation, how do update the viewports?

You have to use methods of JPatchScreen (you can get the instance via MainFrame.getInstance().getJPatchScreen()). On the JPatchScreen object, you can usesingle_update(Component component) to redraw a single component (or all components if synchronize viewports is selected) and full_update() to redraw all viewports.

I'm assuming that something that I don't know about is terribly broken

It's not horribly broken, it's just badly designed :?
Some shortcomings are:
* IK would be very difficult to implement on top of the current bone system.
* Bones are defined by their start and end-points. While the vector start->end defines the z-axis of the bone, it does not define the x- and y-axes (of the bone coordinate system). Currently a heuristic is used to set up these axes. It works well unless you select the entier model and rotate it. In this case, the heuristic might come up with different x/y axes or swap them, messing up the skeleton - this was a horrible design flaw. The new system will use only the bones start position and length. By default the bone is aligned with the world coordinate system (extending in z-direction), and a rotation matrix is used to represent the real default (i.e. reference) orientation of the bone.

I also plan to use a common codebase for implementing bones and transform-nodes (in the scene graph), as the concepts are very similar.
sascha
Site Admin
 
Posts: 2792
Joined: Thu May 20, 2004 9:16 am
Location: Austria

Postby dcuny » Wed Jan 24, 2007 12:29 pm

I'm running into troubles implementing this, because the current control (default, move, rotate) is global for all views, but doesn't make sense in the context of the "shelf" control. Implementing it so things don't break is a real problem, and this whole design is like a twisty maze... One routine sets up a mouse listener, another sets up an event handler, and yet another actually handles the action. My head hurts trying to untangle it. :?

In the meantime, there's a bit of an uproar on the POV Community webpage under the IRTC Stills thread about the IRTC administrators for being absent 25+ days. Apparently, the only one they've been able to track down said he was losing Internet access in November. There's been no response to any queries, and there's serious talk about setting up a new IRTC admin team. The current thread is up to 49 posts, with nary a response from an IRTC official.

Personally, I think it would be a good plan, as there have been serious problems with timliness with the IRTC over the past couple of years.

Oddly enough, Bill Mars (one of the admins) seems to be alive and well, since he updated his blog today. :shock:
dcuny
 
Posts: 2902
Joined: Fri May 21, 2004 6:07 am

Postby sascha » Tue Feb 06, 2007 8:26 pm

On the IRTC newsgroup Chris Cason wrote:We have not heard from Jesse, which is a worry. The other active IRTC admin
(Chip) was holding off in the hope he would respond, since the tasks of
releasing the rounds are usually done by him.

Chip has agreed that the best course right now is to release the round for
viewing, which will be done within 24 hours. Voting will not be enabled at
this point.

With respect to the direction to take for the future ... I have some
comments regarding this. I will make that shortly in a new thread.

regards,

-- Chris Cason
sascha
Site Admin
 
Posts: 2792
Joined: Thu May 20, 2004 9:16 am
Location: Austria

Postby dcuny » Tue Feb 06, 2007 11:40 pm

It looks like the topic of the current round has finally been announced - "Space Settlements".

It doesn't spark of any immediate desire to start animating something. :?
dcuny
 
Posts: 2902
Joined: Fri May 21, 2004 6:07 am

Postby dcuny » Sun Feb 11, 2007 8:41 pm

I've been kicking around the idea of a "home in space". More specifically, a kid imagining they live in some home in outer space.

One idea focus on a kiddie rocket ride, like those horses and carousels that sit outside of stores. When he's on the ride, he's transported into space, in some fantastic future world. Then the ride ends, and he's back to Earth.

I'm not sure what the core of the story is, through. Should it be on the kid, who's trying to escape a drab reality, or the conflict between the kid trying to get a quarter out of his harried parent who just want to get home, or (like Pixar's "Red's Dream") the ride itself?

And all that's ignoring the various constraints of actually getting the animation done. :?
dcuny
 
Posts: 2902
Joined: Fri May 21, 2004 6:07 am

Postby sascha » Sun Feb 11, 2007 9:07 pm

If we'd ignore the "settlement" in the topic...

1: IRTC museum, our clerk watches something on his monitor.
2: OTS, we see the screen with the movie. It's a space scene, a large, cubic spaceship approaches the camera, passes the moon and disappears, heading towards earth.
3: Full shot of clerk, watching the movie. We hear the doors open and footsteps coming closer.
4: Something like a red laser scans the clerks face. He looks up and is frightened.
5: OTS, two Borg are standing at his desk. "You will deliver our IRTC animation awards. Resistence is futile."
6: Clerk reaches for panic button, we hear the trap-door open and then the clerk scream.
7: Credits
8: Clerk, as a borg, turing to the camera: "You will be assimilated..."
END

Let's hope there are some trekkies among the judges :?
sascha
Site Admin
 
Posts: 2792
Joined: Thu May 20, 2004 9:16 am
Location: Austria

Next

Return to General discussion

Who is online

Users browsing this forum: No registered users and 1 guest

cron