Progress Report?

Discussion about the next release of JPatch, with support for subdivision surfaces (SDS).

Progress Report?

Postby dcuny » Sun Oct 14, 2007 2:40 am

Sascha, and progress to report? Still got the coding blahs? If so, is there anything we can do to motivate you? :P
dcuny
 
Posts: 2902
Joined: Fri May 21, 2004 6:07 am

Re: Progress Report?

Postby sascha » Sun Oct 14, 2007 9:25 am

Coding mood is back, but the lack of sleep at night somehow makes me feel tired in the evening. I guess that in a few month the kids (especially Noah, who's 14 month old now) will sleep a bit better, so our lives will feel more normal again and I don't fall into bed at 10 in the evening. But don't worry, there is some progress, stay tuned...
sascha
Site Admin
 
Posts: 2792
Joined: Thu May 20, 2004 9:16 am
Location: Austria

Re: Progress Report?

Postby dcuny » Sun Oct 14, 2007 10:08 am

sascha wrote:...but the lack of sleep at night somehow makes me feel tired in the evening.

Yeah, that one's a real puzzler, isn't it? ;)

I guess that in a few month the kids (especially Noah, who's 14 month old now) will sleep a bit better, so our lives will feel more normal again and I don't fall into bed at 10 in the evening.

My coding schedule never quite recovered from having kids. Although I'm not up late at night with them, we tend to go to sleep late in my house. That means the kids aren't in bed before midnight - they're "ready" for bed by 10:30ish, but then comes the round of stories for the girls, and then the boys. After that, there's a good chance that my wife will want to unwind on the computer for a while, so it might not be free until 1:00. That doesn't leave a whole lot of time for coding.

But the real timekiller is the internet. Back in the "old days", we only had dialup. I'd pop a CD into the computer, focus on a problem, and code away. Now, there's a good chance I'll get distracted browsing around, and never get around to coding in the first place. :?


But don't worry, there is some progress, stay tuned...

Excellent! :D
dcuny
 
Posts: 2902
Joined: Fri May 21, 2004 6:07 am

Re: Progress Report?

Postby dcuny » Tue Oct 23, 2007 9:07 pm

sascha wrote:But don't worry, there is some progress, stay tuned...

Bump. :P
dcuny
 
Posts: 2902
Joined: Fri May 21, 2004 6:07 am

Re: Progress Report?

Postby sascha » Tue Oct 23, 2007 9:26 pm

Yes, yes, yes.

The rotate tool was 95% finished when I found out that I've got no clue about what (or better how) it does. It juggled around with various transformation matrices, some operations were performed in local space, others in world space, others in camera space and finally some in screen space. Long story short, it worked, but was unmaintainable - and I didn't want to implement the other tools that way too.

So I wrote a class called TransformUtil - clients can set a local transformation and the camera matrix (and screen projection parameters) are automatically set by viewports. It computes all matrices (and there inverse) needed to convert from one space to another, and better yet, it caches them for optimum performance. One of the most useful classes I ever wrote ;-)

I've changed most of the code, including the rendering code, to use this new utility and rewrote the rotate tool to use it too - the code's much more readable now, and even if there were an error in all this matrix mess, it's in a single place now (namely the TransformUtil class) and can be fixed easily.

I'll put something with working select, rotate, translate and scale tools online shortly.
sascha
Site Admin
 
Posts: 2792
Joined: Thu May 20, 2004 9:16 am
Location: Austria

Re: Progress Report?

Postby sascha » Wed Oct 31, 2007 10:21 pm

Some good news:

The rotate tool is done. It looks nice, and best of it all, it works ;-)
Undo/redo works just fine too.

One problem was performance: JPatch stores the positions, limits and normals of the level-2 mesh (the mesh after one level of subdivision). During rendering this information is used to either render each face of this level-2 mesh or, if necessary, tesselate it with the dicer up to level 6. This all works fine and nicely adapts the subdivision level as you zoom in/out. The problem was that if a top-level vertex has been moved, JPatch had to recompute the entire level-2 mesh. Not a big deal if the mesh is small, but in case of the cartoon rabbit it severely hit performance - just rotating the view was very fast, but when manipulating even a single point, refresh rate was noticeably slower. The solution was to use lazy evaluation: When a top level vertex is touched, it invalidates all the level-2 vertices that are influenced by it, and prior to rendering only the invalid level-2 vertices are re-evaluated - this is much faster when manipulating only a portion of an object (which usually is the case).

I'll see how far I can get with the move and scale tools (which are quite primitive compared to the rotate tool), but in any case I'll upload what I've got so far this weekend so you can play with it.

The next milestone is adding tools to change the topology (lathe, extrude, etc.). Because of the half-wing structure used these operations should be fairly straight-forward to implement. Once done, we'll have a basic SDS modeler ready and I'll release it as 0.7 development branch with regular updates.

Further steps will be bones and morphs, more sophisticated modeling tools, constraints and a new motion-curve editor.

Hierarchical SDS models will not be implemented until a stable version (0.8 ) has been released, so I plan to start with it in development branch 0.9.

GPU based subdivision is deferred for now. I've played with the netbeans profiler and discovered that the software dicer is extremely fast. Most CPU cycles go into maintaining the level-2 mesh (the dicer can only kick in at level 3), projecting from local to camera space and arm the dicer with prepared face data. When the entire model is shown, most faces are rendered at level 2, so the dicer is virtually unused. When zooming in, fewer and fewer faces are rendered (at higher levels) and rendering becomes faster and faster.
So a dicer implementation in hardware would barely improve the performance - it could be used to tesselate to higher levels per default (improving quality), but that's not a priority issue.
sascha
Site Admin
 
Posts: 2792
Joined: Thu May 20, 2004 9:16 am
Location: Austria

Re: Progress Report?

Postby dcuny » Thu Nov 01, 2007 10:05 am

sascha wrote:The rotate tool is done. It looks nice, and best of it all, it works ;-)

I'm looking forward to this weekend. :D

The solution was to use lazy evaluation: When a top level vertex is touched, it invalidates all the level-2 vertices that are influenced by it, and prior to rendering only the invalid level-2 vertices are re-evaluated - this is much faster when manipulating only a portion of an object (which usually is the case).

Sounds like a good optimization.

The next milestone is adding tools to change the topology (lathe, extrude, etc.). Because of the half-wing structure used these operations should be fairly straight-forward to implement. Once done, we'll have a basic SDS modeler ready and I'll release it as 0.7 development branch with regular updates.

Excellent!

What sort of import types will be supported for the initial release?

Further steps will be bones and morphs, more sophisticated modeling tools, constraints and a new motion-curve editor.

So what's the naming convention here? The "minimal" version is called 0.8 at this point?

I've played with the netbeans profiler and discovered that the software dicer is extremely fast.

Proof again that it's smart to check that code needs optimization before you actually start optimizing it. ;)
dcuny
 
Posts: 2902
Joined: Fri May 21, 2004 6:07 am

Re: Progress Report?

Postby sascha » Thu Nov 01, 2007 11:00 am

What sort of import types will be supported for the initial release?

JPatch patch models, .off and .obj files, perhaps .mdl (A:M) too. For the patch model "volume compensation" I've had a nice idea: When applied at 100% to model gets too distorted. So it would be nice to have a slider to adjust the amount of compensation after the import. Why not add a morph that does exactly that?

So what's the naming convention here? The "minimal" version is called 0.8 at this point?

Development versions have odd minor numbers, stable versions even. Since 0.5 was abandoned and thus a 0.6 version never came out, I thought I'd start with 0.7 for the current development branch, and the next stable release will be 0.8.
This "minimal" version is for me just the order in which features will be added. So it's most likely that at some point a 0.7.x version will have all the features of the minimal version. Right now I can't tell if I'll stop adding new features then and strive for a stable 0.8 release, or if I'll add more features to the 0.7 branch before.

Proof again that it's smart to check that code needs optimization before you actually start optimizing it.

It would still be a cool thing to have. When run on a fast GPU it should, in theory, be able to tesselate to sub-pixel level in realtime - instead of rendering and mpeg-compressing a movie, one could distrbute the JPatch files and the movie gets rendered in realtime :-)
Its not a must have for the modeler though, I'm happy with the software solution too.
sascha
Site Admin
 
Posts: 2792
Joined: Thu May 20, 2004 9:16 am
Location: Austria

Re: Progress Report?

Postby sascha » Sat Nov 03, 2007 1:12 pm

As I said, I don't know how much time I can spend on JPatch this weekend, so to keep my promise, here's what I've got so far:

jpatch_20071103.jar

Here's a list of the most obvious things that do not work:
  • OS X only: Instpector form background is black, Lasso select doesn't draw overlay rectangle
  • Move tool doesn't do anything
  • Undo/redo currently only active with rotate tool
  • Tool's don't work correctly in local space (if you modify the model's transformation) - you can move the camera though.
  • Rotate tool doesn't rotate geometry when text-input is used
  • The "snap to grid" and mode (vertex, edge, face, object) buttons are not doing anything
  • The rotate tool's pivot can only be moved via text-input

If you're having performance problems on Windows, try starting it with -Dsun.java2d.noddraw=true.

You can switch to a camera view and test the tools in perspective mode too. To actually see something, move the camera infront of the object (enter 100 in the Translation Z field) and turn it around (enter 180 in the Rotation Y field).

Here's what should work:
  • Start up, check JOGL installation and offer to install JOGL if necessary
  • Load .jpt models
  • Use the tree and the inspector panels
  • Use the default tool to move single vertices and to lasso-select (no undo/redo yet).
  • Use the rotate tool (undo redo should be fully functional)
  • Display the translate tool (not fully functional yet)
  • Switch between single, split and quad viewport modes
  • Move/Zoom/Rotate view (also via text-input and in camera mode)

I try to have translate and scale tools running by the end of next week, and I also try to fix most of the problems listed above.
I the meantime, please let me know what you think.
sascha
Site Admin
 
Posts: 2792
Joined: Thu May 20, 2004 9:16 am
Location: Austria

Re: Progress Report?

Postby dcuny » Sat Nov 03, 2007 8:16 pm

sascha wrote:As I said, I don't know how much time I can spend on JPatch this weekend, so to keep my promise, here's what I've got so far:

Got it, thanks. :)

If you're having performance problems on Windows, try starting it with -Dsun.java2d.noddraw=true.

I'm having performance problems on Linux. I think it's related to the mesh evaluation, because when I loaded a really lightweight model vase, the interface zoomed. So fixing that would help a lot!

You can switch to a camera view and test the tools in perspective mode too.

Yep, it works.

It helps to change the focal length to 90, or something sensible. Using the Zoom tool changes the focal length - that certainly does some fun stuff to the Rotate tool. :)

Start up, check JOGL installation and offer to install JOGL if necessary

Works OK. I had to run as administrator. Too bad you can't toggle JOGL from within the project. :(

Load .jpt models

Yes. It helps to load a model with the patches properly flipped.

Use the tree and the inspector panels

No problems here. There doesn't seem to be a way to turn off the Vertices in the list, though.

Use the default tool to move single vertices and to lasso-select (no undo/redo yet).

Seems to work OK. The selected vertices don't change color yet. Hrm... I see points selected via the lasso tool do, so it's not a big issue. I guess it's too early to start on these sorts of things.

Use the rotate tool (undo redo should be fully functional)

It took a bit of playing with the tool before I figured out that JPatch's Rotate doesn't work like other people's rotate tool. On most tools, when you select an axis, the tool measures the distance the mouse has moved from the original position as a measure of the number of degrees to turn the object.

That is, it doesn't care where the mouse is, only how much it's been moved.

JPatch tracks where the mouse is relative to the rotation axis, and rotates appropriately.

Yeah... You know this already, since you implemented it. And I should have remembered it, but I didn't really pay attention until I tried a free rotate. Then, it sort of "broke". That is, the "free rotate" stops working as soon as the mouse is outside the rotate widget's sphere. This is... odd, in not a good way. More problematically, I think it'll baffle new users who will think it's broken and not explore any further.

A couple of suggestions:
  • With the current tool, there's no indication which axis you've selected until you start moving the mouse. That's a bit confusing. Instead, hide everything but the selected axis when the mouse goes down.
  • To make it clear that you're tracking the position of the mouse (and not just the amount of movement), you might also draw a (much lighter) wedge from the center to the current mouse position. I dunno, it needs something to help indicate how it's working.
  • The "free rotate" tool feels broken. I think I'd like it better if it stayed in "free rotate" mode for up to some number of pixels around the mouse down position, and then locked to that axis after it got past the maximum point, and behaved like the rest of the axis rotate tools after that.
I'll play around with it some more (and Blender as well) to get a feel for how they both work. All opinions are subject to revision. ;)

Display the translate tool (not fully functional yet)

It appears, all right. You'll probably need a control for toggling which space the tools should be oriented in. I found the toggle for 6/3 arms too. :)

Switch between single, split and quad viewport modes

I can't do that. I can toggle a single viewport, but there doesn't seem to be a way to toggle multiple viewports.

Move/Zoom/Rotate view (also via text-input and in camera mode)

If there are hotkeys, I can't seem to find them.

In general, the interface is pretty slick.

I wonder if the Default tool is misnamed. It's really a Select tool.

I've got mixed feelings about the View modes (Move View, Zoom View and Rotate View) being separated from the other modes. You could argue that the Default tool doesn't really warrant being with the Move, Scale or Rotate tools. I find that I keep selecting Move View, and then forgetting to toggle it off. I dunno, it's not really wrong, maybe I'm just used to the auto toggle off behavior it used to have.

Having to install the JOGL libraries is a potential issue for users, especially if they're worried about running something as Admin. How does WebStart get around this? Perhaps you could create versions with the native libraries pre-selected? Eclipse seems to allow this.

Anyway, thanks... Now I've got another distraction for the weekend. :D
dcuny
 
Posts: 2902
Joined: Fri May 21, 2004 6:07 am

Re: Progress Report?

Postby sascha » Sat Nov 03, 2007 11:53 pm

I'm having performance problems on Linux.

Can you be more specific? I've tested it with the cartoon rabbit, because it's got about the level of detail I strive for. When fully visible I get about 10fps, when I zoom in it gets a lot faster, so I think this is ok. More complex models don't really make sense. I can't tell how well it will work when 5 or 6 such models are used in an animation, perhaps I'll have to render just the control mesh (not the sds limit surface) of the not-selected models to speed rendering up a bit.
It helps to change the focal length to 90, or something sensible.
The focal length is in millimeters, relative to a 35mm photo camera (aperture width = 36mm), so every value between 15 (extreme wide angle) and 400 (extreme telephoto) should be sensible.
Using the Zoom tool changes the focal length
Isn't that what cameras do when using the zoom? What else should it do? :)
that certainly does some fun stuff to the Rotate tool
Well, when viewed through a 10mm lense, everything looks odd, including rotate tools. I could try to change the algorithm that computes the rotate tool's sphere radius based on the focal length to compensate for ultra wide angles, but I don't think that anything below 16mm is practical.
It took a bit of playing with the tool before I figured out that JPatch's Rotate doesn't work like other people's rotate tool.
I need some time to be able to get used to it before I can decide which method works best. For the axis constrained mode I didn't like JPatch <0.5's mode, I think the way it works now is somehow more intuitive, and even if it's not, one should be able to adapt to it quickly. I agree about the axis display upon mouse-down, I'll change that. The unconstrained rotate mode is more complicated. The metaphor used is that of a sphere, rotated with your hand. You grab it at one point and move that point (on the sphere) when dragging, thus rotating the sphere. Since you can't see the back-side, you can't rotate it any further when the mousepointer is outside the sphere. Again, I think this is quite logical, and maybe even intuitive once you know what it's doing. I'll need some time to play with it before deciding. As fas as I have seen, Blender doesn't have a "rotate freely" mode, at least I couldn't find it.
I can toggle a single viewport, but there doesn't seem to be a way to toggle multiple viewports.

I've you want to select viewports 1 and 2, for example, press the mouse over the 1 button, drag it over the 2 and release it. The same works for 3+4, 1+3, 2+4 and 1+2+3+4. I know exactly what you're going to say now, but consider the alternative: Either 9 buttons, or a dropdown list with 9 elements. The first occupies too much screen real estate, and the latter is inconvenient to use: You'd have to click on the dropdown and then search for the right option. With my control, you can switch between viewport modes in a matter of nanoseconds, once you know how it's working. I too tend to like "intuitive" solutions where the user doesn't have to read hundreds of manual pages, but in this case I think the benefits of the "non-standard" solutions outweights that. Perhaps JPatch should start-up in quad-viewport mode, so the used knows that there must be some possibility to switch it back into that mode once he clicked on the viewport-switcher, so he might try and find it out, or, if all else fails, rtfm.
Move/Zoom/Rotate view (also via text-input and in camera mode) ... If there are hotkeys, I can't seem to find them.
There are hotkeys, but I think I haven't assigned keys yet. What I meant was that you can type in the translation and rotation in the viewport's inspector panel as well.
I also agree that these tools should switch back to the default once the mouse has been released (or at least this should be a configurable option). But I'll also add the middle-mousebutton mode again, so expirenced users won't need the move/zoom/rotate-view buttons at all (middle-drag = move, CTRL-middle-drag = rotate, scrollwheel = zoom).
How does WebStart get around this?

I think WebStart kicks in before it starts up the JVM, so it's able to set all these things up beforehand. The -jar option can't do that, it starts the JVM before reading the jar file - unforunately. One day I'll use a real installer that will install the dlls into the right directory. In the meantime, if you don't have root/admin privileges, you can still set the library path to a directory you've got access to (read the fine print in JPatch's JOGL installer ;-) )
sascha
Site Admin
 
Posts: 2792
Joined: Thu May 20, 2004 9:16 am
Location: Austria

Re: Progress Report?

Postby dcuny » Sun Nov 04, 2007 6:27 am

sascha wrote:Can you be more specific?

Is there a FPS option that I can see?

I've tested it with the cartoon rabbit, because it's got about the level of detail I strive for. When fully visible I get about 10fps, when I zoom in it gets a lot faster, so I think this is ok. More complex models don't really make sense. I can't tell how well it will work when 5 or 6 such models are used in an animation, perhaps I'll have to render just the control mesh (not the sds limit surface) of the not-selected models to speed rendering up a bit.

All things being equal, a responsive program is more important than being able to see fine detail. So I'd rather have a low resolution object that was easy to manipulate than a high resolution object that was slow.

Isn't that what cameras do when using the zoom? What else should it do?

Augh! No! Zoom should move the position of the camera or eyepoint along the viewing axis. Changing the focal length would be the last this I'd expect to happen.

The focal length is in millimeters, relative to a 35mm photo camera (aperture width = 36mm), so every value between 15 (extreme wide angle) and 400 (extreme telephoto) should be sensible.

Ah. I confused focal length with field of vision.

Well, when viewed through a 10mm lense, everything looks odd, including rotate tools. I could try to change the algorithm that computes the rotate tool's sphere radius based on the focal length to compensate for ultra wide angles, but I don't think that anything below 16mm is practical.

I don't think it'll be a real issue.

For the axis constrained mode I didn't like JPatch <0.5's mode, I think the way it works now is somehow more intuitive, and even if it's not, one should be able to adapt to it quickly.

Hrm... I just played with Blender's rotate tool, and it works exactly the way your tool does. :oops: I don't have access to any other programs to try it out on, so I can't compare. But you can ignore my complaints about users of other software, since I'm guessing that JPatch will primarily attractive to people who gave up on Blender.

The unconstrained rotate mode is more complicated.

I understand the metaphor, I just don't like how it stops when you move outside the sphere limits. It just feels wrong. I'm not sure that my suggestion is any better.

Most of the animation process consists of moving the character from one pose to another. So I think it's important to have tools that "just work" and don't interrupt the flow. The most used tools are probably Move and Rotate. Move is probably most in conjunction with IK, and Rotate is probably used with joint rotation.

I'm not quite sure what the use case for the "free" Rotate would be, so I'm a bit hesitant to claim I've got a clue what I'm talking about. But I am fairly confident that if you come up with a solution that doesn't stop dead when the mouse exists the tool's range, it'll be better than what you've currently got. ;)

Since you can't see the back-side, you can't rotate it any further when the mousepointer is outside the sphere. Again, I think this is quite logical, and maybe even intuitive once you know what it's doing.

Urm... Well, a trackball doesn't suddenly stop rotating when you reach the edge - you can still spin it.

As fas as I have seen, Blender doesn't have a "rotate freely" mode, at least I couldn't find it.

You're right. That bugs me.

I've you want to select viewports 1 and 2, for example, press the mouse over the 1 button, drag it over the 2 and release it.

:shock:

I know exactly what you're going to say now, but consider the alternative: Either 9 buttons, or a dropdown list with 9 elements.

Here's how it works in DazStudio:
daz_layout.png
daz_layout.png (7.97 KiB) Viewed 10325 times


But I think that's too much - there are really only four options that you're offering:

  • One viewport.
  • Two horizontal viewports.
  • Two vertical viewports.
  • Four viewports.

Seems to me easy enough to do. ;)

But I'll also add the middle-mousebutton mode again, so expirenced users won't need the move/zoom/rotate-view buttons at all (middle-drag = move, CTRL-middle-drag = rotate, scrollwheel = zoom).

Yes, I miss that option.

I think WebStart kicks in before it starts up the JVM, so it's able to set all these things up beforehand. The -jar option can't do that, it starts the JVM before reading the jar file - unforunately. One day I'll use a real installer that will install the dlls into the right directory. In the meantime, if you don't have root/admin privileges, you can still set the library path to a directory you've got access to (read the fine print in JPatch's JOGL installer ;-) )

Ultimately, an installer would be a good thing. My recollection was that AoI had been working on a nice installer.
dcuny
 
Posts: 2902
Joined: Fri May 21, 2004 6:07 am

Re: Progress Report?

Postby sascha » Sun Nov 04, 2007 11:12 am

Is there a FPS option that I can see?

I can activate that again, yes. But I still don't know what the problem is. Can you send me the problematic model?
You can turn off "Limit Surface" in the Rendering section of the viewport inspector. There's still room for optimization though.
Zoom should move the position of the camera or eyepoint along the viewing axis. Changing the focal length would be the last this I'd expect to happen.
I'm afraid I have to protest. According to Wikipedia "A zoom lens is a mechanical assembly of lens elements with the ability to vary its focal length (and thus angle of view)", and I've never noticed my camera moving when I put a zoom lens on it and zoomed. :)
It's also consistent, given that the "move view" tool, when applied to a camera, doesn't move the camera, but pans (i.e. rotates) it (while rotate view tilts the camera). I see that there is a need for a move-camera tool (other than selecting and moving the camera in a different viewport), but this is more tricky than you might think: The camera doesn't know if it's viewing a microbe .5 millimeters away, or a distant galaxy some lightyears away. If you'd use the mouse (or scrollwheel) to move the camera, how much should it move with each dragged pixel? One micrometer, one meter, one mile, one parsec? This obviously wouldn't work (ideas welcome).

My approach to this problem would be the following: The "move camera" tool needs a reference object. So in essence, it would work like the "translate object" tool, but would move the camera instead of the object. E.g. if you want to move the camera to have an object centered on the screen, select the "move camera" tool and then simply move the object to the center of the screen.

This might not be the best option, but it's the best one I came up with - suggestions appreciated.
Well, a trackball doesn't suddenly stop rotating when you reach the edge - you can still spin it

Well, no, not really. You'll have to raise your finger, move it over and spin it again - The rotate tool works exactly like that (release the mouse button, move the pointer over, and drag again). I've seen interfaces where you can give the "rotate tool" some kind of momentum, and it keeps spinning after you release the mouse (Google earth for example), but I hate that.

I too see the problem, and I'd love to have a solution for it - I too don't like it that the rotation stops when the pointer is outside the sphere, but I can't think of an algorithm: The current algorithm works as follows:
1. On mousePressed, compute the intersection of the ray shot from the viewer through the viewscreen at mousex/mousey with the rotate-tools sphere. Set vector "A" to the vector from the pivot (shpere center) to the intersection point.
2. On mouseDragged, do the same with the current mousex/mousey and store the result in vector "B".
3. Compute A x B (cross product), this yields the axis of the rotation. Compute A . B (dot product), this yields the cosine of the angle.

I've experimented with other modes (compare the older JPatch's rotate tool), but they all suffer from gimbal lock and are not very intuitive. The new tool is (IMHO) much more intuitive as long as the pointer stays within the sphere.
I like the idea and I'll give it some thought, perhaps I can come up with a solution that also works outside the sphere in a consistent and intuitive way.

Here's how it works in DazStudio:

I've had a similar dropdown implemented, and it was a pain to switch viewport modes (compared to JPatch 0.4, which simply had 4 buttons side by side).
* One viewport.
* Two horizontal viewports.
* Two vertical viewports.
* Four viewports.

That's exactly what JPatch 0.4 offered, but it had one problem: Single viewport mode always showed viewport 1 (the upper left one), so if you had 4 viewports visible, worked e.g. in the lower right one and needed to temporarily "zoom into" this viewport, it didn't work. With the new tool, you just click on viewport 4 in this case.
The new tool overcomes all these problems: It's relatively small, it doesn't rely on a dropdown and its responsive. The only downside is that the "drag to select" mode isn't obvious to first time users, but this could be explained with a tooltip.

What do you think?
sascha
Site Admin
 
Posts: 2792
Joined: Thu May 20, 2004 9:16 am
Location: Austria

Re: Progress Report?

Postby rjh » Mon Nov 05, 2007 1:33 pm

Hey Guys,

As far a Zoom goes:

"Using the Zoom tool changes the focal length"
and
"Isn't that what cameras do when using the zoom? What else should it do?"

I have to agree with Sascha. A "zoom" should change the focal length. A "dolly" moves the camera.

Rob
rjh
 
Posts: 179
Joined: Thu Dec 30, 2004 10:33 pm

Re: Progress Report?

Postby dcuny » Mon Nov 05, 2007 6:52 pm

sascha wrote:Can you send me the problematic model?

Any nontrivial mesh is problematic. In Move View, my mouse often gets up to 16cm ahead of the model.

You can turn off "Limit Surface" in the Rendering section of the viewport inspector.

This speeds things up considerably, but Rotate View still isn't smooth, and Move View still has a lag of about 2cm between the model and the mouse.

A responsive interface always beats a pretty interface in my books.

It's also consistent...

Having the Perspective Camera behave differently than the other Views seems inconsistent to me.

I don't disagree what "Zoom" technically does. I just disagree with what the button does. I also think the name "Zoom" is more intuitive to users, even if it describes something different. I don't know if most users would understand the term "Dolly" or "Truck", even if they are technically correct. What the behavior should do is move the camera, not change the lens.

Optimally, the Move View would work in 3 dimensions, but because of the limitations of the mouse, you need another button. If you check out other applications, I think you'll find the behave the way I'm describing. (At least, that's the way Blender seems to behave).

If you'd use the mouse (or scrollwheel) to move the camera, how much should it move with each dragged pixel? One micrometer, one meter, one mile, one parsec? This obviously wouldn't work (ideas welcome).

There are several "scales" you need to deal with. One is for physical materials, so simulations (like subsurface scattering) work correctly. This is a "JPatch Units -> World Units" sort of thing.

Another scale is what we're talking about here. I'll call it "Camera Scale" - it relates to the size of the camera, and the ratio of movement. I'd expect this to be a property of the camera.

Well, no, not really. You'll have to raise your finger, move it over and spin it again - The rotate tool works exactly like that (release the mouse button, move the pointer over, and drag again). I've seen interfaces where you can give the "rotate tool" some kind of momentum, and it keeps spinning after you release the mouse (Google earth for example), but I hate that.

Both are compelling reasons to hate the trackball.

Play with DazStudio - it may not be the best solution, but figuring out how their tool works is a starting point.

The only downside is that the "drag to select" mode isn't obvious to first time users, but this could be explained with a tooltip.

Buttons should behave like buttons.

To get the behavior you want, just add a "Maximize Current Viewport" button.
dcuny
 
Posts: 2902
Joined: Fri May 21, 2004 6:07 am

Next

Return to JPatch SDS Minimal Development

Who is online

Users browsing this forum: No registered users and 1 guest

cron