Hi for quite some time, I have been thinking of thoroughly renewing the view manipulation system of Art of Illusion. I like this style of modelling a lot, but over the years I have had to leave some projects on hold indefinitely because the view manipulation makes doing detailed work very difficult and I also know, that I'm not alone with that.
At first a few words about myself:
I have had the chance of watching the development of 3D-modelling for well over 20 years now. My first experiences were somewhere in the late 1980's with a WAX/VMS-system, that had things like "Boxer" and "Swans" to do basic boolean modelling and creating surfaces. Boy, was that slow!
I guess view manipulation was not considered to be an issue at those times. Now, since the year 2000 3D-modelling has been to me an essential part of making my living as a mechanics engineer. In that world a fluent and intuitive view manipulation system is a must. If the behaviour of view manipulation is not intuitive, it breaks the flow, when you are trying to concentrate on the details of your design and that software simpy has no future in the business.
Now, what I'd like to do is to offer my learnings out, to bring the view manipulation of AoI into the level where it deserves to be: To have professional level detailed modelling happen effortlessly. Sadly, what I have seen over the years is, that these things are hard to explain in writing, without the hands-on experience on it, so I'm afraid I'll need to do a lot of the work myself. Let's see how it works out. I know there are areas in there, that are unknown to me so far and I don't have much official education in software development. Most of the practical stuff I have learned about writing Java code happened by hacking AoI.
So to the business (current state):
I'm not going into the details of the current state of things. Let's just say, that it is a combination of different ideas, that do not work very well together. I can even see some of my own inputs in there. Also, a few years ago, I was trying to build a plugin for view manipulation but eventually it turned out, that some things are so deep, that a plugin can not respond to the user's commads quickly enough (if at all) to produce consistent behaviour.
The good thing, that I found out, is that the mathematical code behind the system is well capable of anything needed and also there are some features to the current system, that I like even better than in the engineering tools that I have used.
Then to the goals:
What I'd suggest is, that there would be two basic modes or mode sets to the view manipulation, Model and Explore.
The Model-mode is designed for doing either detailed modelling of objects or arranging scenes. It should be adaptive to the size of the current work and should be able to switch between parallel and perspective viewing with the adaptivity included. The Explore-mode could only produce perspective viewing as it is meant for travelling inside the model space. The Explore-mode could be used for example to design camera drives for animation.
The Model-mode should probably be split into two sub-modes, that could be called 3D and Landcape.
The 3D mode(And trust me, this is the way a serious 3D-modeller wants it!) would be one without a preferred up-direction. The "up" is always the up of your screen an you can turn the view into any direction you need to from your current orientation. The rotation center (or your point of focus) stays where it is while you rotate and moves with the view, when you move the view, so that it always is in the center of the view. The 'drawing plane' (or 'Screen' in AoI terms) is always fixed to the rotation center.
The Landscape mode would basically be a tilt locked version of the 3D, actually quite close the current behaviour, having the Y as the preferred 'up' and some limits to things like, how far forward or back you can tilt the view. Eventually it should have the option to select the 'preferred up' freely, but at this point I'd give that a lower priority.
The Explore modes come currently in many forms in different software packages. They may be called things like 'Walk', 'Drive', 'Fly (airplane), 'Fly (space ship)'. Some even come with game-engine-like real time animation systems.
As the starting point I'd introduce something with resemblence to the Google Earth approach: You can place yourself into the model and then point or scroll-wheel, where you'd like to go next. In this mode the rotation center would be the camera itself. The viewing angle could be a bit wider than in modelling modes and preferably user-adjustable. (AoI CAN do that, though right now I'm not sure how it happens.)
The first steps:
As the first thing I'd add a View menu to the scene window. There would not be much left in the Scene menu, but these are separate areas to deal with and view manipulation needs more options.
Next I'd probably add animations to the 'quick-moves', like switching between viewing directions. That has been pretty standard in engineering tools for over ten years already and I have an animation module ready in the plugin attempt. There are some minor issues to fix, but most of the time it works quite nicely.
And yet another thing: If this thing takes off properly, at some point it might become tempting to add automated (say game-camera-like features) to the system. For any automation there is one rule, that must be obeyed without exception: The user has to have the choice to use it or not. This actually goes with the animated moves as well.
Then some practical points:
Unfortunately view manipulation is not just one file or one module in the code. It is scattered all over the place into parts that interact with each other.
Working in that environment will require changes into a number of files and it will take a lot of time, fixing one issue at the time, while not forgetting the future goals. This also means that more information needs to be passed between different parts of the software than before. New variables need to be defined, old ones may be removed... Possibly some kind of a master list or master object could be created to watch over the actions. (I had something like that in the plugin. If such a master could be created, it could -- at least theoretically -- become a receptacle for plugins, that would add new features to the viewmanipulation system.)
All the above could also mean, that some plugins may stop working until somebody reconfigures them. However, to my mind, the priority of those can not be very high in the bigger picture.
Finally:
Any further thoughts? I know, I may be looking deep into the future with some of these ideas, but hey: Man did visit the moon and came back!
I'm now starting to take my first steps in the wonderland of GitHub, trying to add the View menu. Let's see, how badly I'll mess things up, ;)
BR
-Pete-
Last edit: Pete 2016-10-18
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The view cameras do not have that property. Instead, there is a fixed relation between the perspective strength and the parallel mode, so a larger view has a wider angle. That actually works very nicely as the user's perception of the perspective stays the same regardless of the size of the view. On a scene camera the perspective strength depends on the FOV and image is scaled along witn the view height.
But:
The viewing angle could be a bit wider than in modelling modes and preferably user-adjustable. (AoI CAN do that, though right now I'm not sure how it happens.)
This is a bit of a different case.
Working on the plugin I acccidentally bumped into somethig, that actually changed the perpective stength of the editing views. A long matrix calculation that prpbably was not even meant to do that and definitely was not supposed to be used. -- But figuring out how that worked (and having a look at what FOV does in the SceneCamera) would lead to creating a user setting for perpective strength. Usually that option is available to users and the comfortable (natural) setting basically depends on the distance between your eyes and the display.
Anyway: I pushed my first changes to GitHub, but it seems, that I did not quite manage follow the rules/practices. In that case just bounce it back and I'll try again. :)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
BTW. Let's not let this delay the release of 3.0.3 -- maybe 3.1 could be the next possible target for it. -- It seems that I had almost everything needed (except for the Explore mode) in the plugin at least in some kind of a form.
-P-
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
For the overall project, I agree. Many of these changes are likely to require multiple rounds of testing and feedback, so I'd prefer to defer them for another release.
Just moving the view options to their own menu, as you already have, is small enough that I'm not going to delay that bit. I'm going to add a few notes to your PR on github, to help you avoid some potential issues down the road.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I started to work on adding the view animation module and that requires an addition to the preferences table (whether to use the animations or not). So far no problems but I found out, that the artofillusion_en.properties is an empty file in the GitHub master. Any idea, what that is about? Can I just replace that with another one? By some miracle the build still seems to know the English translations except for the addition.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
English translations are actually in the default artofillusion.properties file, without a language code. Its the fallback file if there is no translation in the prefered language.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I would like to see the view's working independently, as presently if I set up a view
in " Left " then change the view in " Top " the " Left " view changes also.
A handy thing would be to be able to save the current view, eg if I view an
object in " Left " view then orbit around it to get just the right angle, the view
changes to " Other ". Something like " save current view as new camera "
or " lock view position " would be very useful.
regards,
chris w.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I would like to see the view's working independently, as presently if I set up a view in " Left " then change the view in " Top " the " Left " view changes also.
I'm not sure if Iquite follow, but the views are supposed to be independent of each other.
A handy thing would be to be able to save the current view, eg if I view an object in " Left " view then orbit around it to get just the right angle, the view changes to " Other ".
You can always return the view to any of the presets by picking for example "Left" from the dropdown menu, (just where it says "Other" after rotating). "Other" simply means that the orientation does not match with any of the presets, Front, Back, Left, Right....
Something like " save current view as new camera " or " lock view position " would be very useful.
I think that could be implemented as user presets that would capture the position, orientation ad scale of the view. Those could be added to the preset list. For the scene window that should be relatively easy but for object editors, I think, those would have to be saved individually for each object. There might be a couple of different ways of doing that. I'll put the idea into the 'thinking cap' -- There's a lot to do before that. :)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I was just working on zoom function of the perspective viewing mode.
As a by product I discovered, that the distToScreen parameter of Camera class actually controls the perpective strength of the view. I was wondering why changing that was dephrecated. Now I may have a hunch... Here is a demo video where the camera (= the viewing point) moves along as the parameter is changing.
I will definitely add using this information to my to-do list. This would make a pretty cool feature for personalizing the software. :)
Interesting idea. I certainly can see cases where it'd be useful. Then think it would be most benefiacial if it would affect both the preview rendering and final image rendering. -- Actually there are some other things too where the SceneCamera (or Camera) and the render engines could interact a bit more.
But for now, clearly a different project. Say, that'd be 'optical' whereas, what I'm on, is more or less 'mechanical'. :)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I meant that the article may give some insights into why the distToScreen element was created in the first place. From you video, the distortion as you vary the parameter seems a lot like what you would get from adding some barrel to th rendered image....
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
the distortion as you vary the parameter seems a lot like what you would get from adding some barrel to the rendered image....
Actually no. It's a pure pinhole perspective. Though you are right that somehow the human perception may suggest that there would be a bit of barrel in it. I had to make another demo to check... The lines stay absolutely straight in this one. (The extra wide FOV somehow messes up drawing the grid.)
Two navigation modes: Space and Landscape.
-- These are available both on Scene and Object windows
-- Currently the Landscape mode does not allow tilting
Center to point by clicking by Center button on an object surface
Animated quick moves to orientation change
Parallel/Perspective switching does not change the scaling at drawing plane.
Drawing objects happens at the depth of the rotation center. (Effectively this provides a drawing plane)
On Preferences you can choose
-- whether to use animations or not and
-- set the maximum duration of animations (time varies according to need)
-- Unfortunately you need to restart AoI for the preferences to become effective.
Some glitces:
Landscape mode may flip from top view to bottom when you drag the mouse too far up or down during rotate
Center to poit does not work with Scene Camera.
More features to be expexted:
Fit view to Scene / Object / Selection to be added to all windows and to be animated.
Travel modes to be added to navigation (Above I called them Explore modes but I felt that, "Travel" is probably closer to what they are for.)
Warnings:
Some plugins may not work. I have tested with PolyMesh and DisplayModeIcons. Those work fine. :)
The forthcoming git push (or two) will be pretty massive. At the moment over 20 files have been edited. It may be possible to split that in half, but in many cases the changes in files are interconnected. At the moment it looks that I'd better to move a thing or two into different places, but nothing major before starting to add the still missing features.
Have fun :)
-- OH! And please post back if you see anything really weird happening!
Last edit: Pete 2016-10-28
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Sounds cool. I'll do some checking in the next day or so. Please do not hesitate to create a pull request - github has a handy interface for developers to discuss and comment right in the code, and you can continue updating the branch as testing and feedback comes in.
Please don't try to split up a pull request if the changes do not make logical sense without each other, its easier to track changes that are commited as a whole. What you have posted to github is not all that big a change, anyway. Only 9 files touched so far, and most of that seems to be fairly simple updates.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
A strange bug appears on the Object Editors (see picture - low right). As soon as I touch any of the tools or the controls of that view or click on the view, the view is corrected. This is related to setting the view to Perspective, but I don't know how. It couldn't seem to be able to repeat this on th eother views and if I use a .bat-file to launch AoI the bug does not happen.
Can anybody repeat that?
Edit 1: Another strange bug: ....
Edit 2: ... that is no longer. :)
Liking it so far. The modes make intuitive sense once you've played with them a bit. I do have a few thoughts:
That flippy thing that happens when you take Landscape navigation too high/low is going to need some work in the long term. The camera should hit a stop at the apex, and refuse to raise/lower further.
I've not been able to duplicate your bug, but it reminds me of an issue that I ran into when testing the original ViewManipulation plugin. I don't think that was ever resolved, either.
I did have an unexpected event of my own. I got into a situation where middle-clicking chose a center that was way off in the brush, in the opposite direction from what I expected. I had to set the veiw to front and rotate a bit up to be able to use the centering function properly again. Not sure how to duplicate.
I've also got a feature request:
It needs a 'Pan' option. camera/view location stays stationary, but the direction changes. Think of the camera being mounted on a stationary tripod.
Should not need to be a separate mode, just a shortcut key, possibly ALT+right-drag to rotate the camera. The 'normal' rotation center should not move.
ALT+Middle-click would rotate the camera in place to face the clicked center point, and set the normal rotation center to it, as usual.
I primarily see the above as useful when tweaking Scene Cameras for rendering. If you have questions/thoughts on the interface, let me know.
I may drop in to leave some code comments tomorrow on github, but now I need to sleep.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
it reminds me of an issue, that I ran into, when testing the original ViewManipulation plugin. I don't think that was ever resolved, either.
I seem to remember that and as I recall the issue was a bit different for both of us. I have been wondering if it would make any sense to have a "cameraShake" method or something like that just to use the views so much, that they'd be updated. repaint(), updateImage, viewChange() etc. seem to have no effect in those situations.
I did have an unexpected event of my own. .... Not sure how to duplicate.
If you find out, let me know.
It needs a 'Pan' option.
Yes, I think that might be a good idea in the modelling modes as well. The (comin) traveling modes are supposed to work that way by default. I feel uncomfortable about severing the rotation center from the camera z-axis even temporarily. That's just the thing, that I have been trying to get rid of. But how about cacheing a set of previous view settings and having a key combination to reverse back to them?
That might be useful, but the scroll wheel action then needs some more work. Somehow it should be decided, what makes one continuous scroll as now each click of the scroll wheel is handled as a separate move. (But the scroll wheel would need that system anyway for other reasons.)
I'll put that into the thinking cap.
Last edit: Pete 2016-10-29
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Now that I've slept on it, and thought it through, the rotation point should be reset once the user releases the mouse from pan mode.
If there is an object in the exact center of the scene, set the center as if he had clicked on its surface.
If there is no object, thats where things get tricky. What is intended behavior when a middle-click is processed with no object?
I've also managed to reproduce my glitch. It seems to happen when clicking to center when in perspective view. Not every time, and not any pattern that I can yet nail down.
And, a specific bug: "Frame selection with camera" and "Frame scene with camera" should only affect the view that is 'active,' that is, that you have most recently:
Navigated in
Moved or selected an object in
Created a new object in, using the create object tools
As it currently stands, these commands adjust all veiws that are not set to a scene camera.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
If there is an object in the exact center of the scene, set the center as if he had clicked on its surface.
That's somethig, I regard as an AI feature, where you can easily go wrong. It sounds like a cool idea, but what if you have built an environment like a park or a city and all of the sudden your rotation center jumps into the horizon? Not so cool, I guess... There should the at least be a switch to turn it off.
If there is no object, that's where things get tricky. What is intended behavior when a middle-click is processed with no object?
Moves the rotation center along with the camera, keeping the distance to the camera same. I think that should be the default for the Pan and also the Travel modes.
I've also managed to reproduce my glitch. It seems to happen when clicking to center when in perspective view. Not every time, and not any pattern that I can yet nail down.
Tried that, but did not have it happen.
And, a specific bug: "Frame selection with camera" and "Frame scene with camera" should only affect the view that is 'active'.
That is not really a bug but an intentional feature. I think there are some kind of historical reasons behind that but I agree, that they should affect just the active view. That should be easy to fix. The getView() of editing windows returns the active view.
I'm thinking of replacing the Frame-commands with new ones anyway. The frameBox() in ViewerCanvas, which does the work for those, is built in such a way that making it animation-capable is not very simple. Have just been schetching a plan in my head, how to do that. :)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Sorry, I'd somehow got the impression that you had already been tweaking the "Frame" commands...
Tracking some of the glitches down is one reason that I think having a way to see the current rotation center in other views would be handy...
When I get the glitch I'm referring to, it almost seems as if the click is not intercepted at the actual object.... I end up sliding off into the sunset, way away to one side (switching to parallel has me hundreds of units away from center. I'll do more testing.
Is there a limit to how far the scroll wheel will go when in perspective mode?
So.... Releasing after a pan move would set the rotation center to 'center of view' at the same distance it was before the pan? Sounds reasonable....
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Sorry, I'd somehow got the impression that you had already been tweaking the "Frame" commands...
I did mention that as a plan, and the plugin had some kind of a work-around to it.
I think having a way to see the current rotation center in other views would be handy...
That and a few other things. I had a look at the drawLine() and renderLine()methods, but though they are made public, they need to be called from inside the updateImage method, to leave anything visible on the screen.
I think it would take something like drawTemporaryGraphics() that would take care of visualizing, what ever was considered necessary. -- And again, a tag in the Preferences if to show or not.
I end up sliding off into the sunset, way away to one side (switching to parallel has me hundreds of units away from center). I'll do more testing.
I still have not had that happen to me. There is a somehow similar problem in the VM plugin, though and I never found out what exactly caused it. I suspect something like the viewChanged() driving the camera move to loop... But if it happens randomly, it may be hard to find. Let's hope it reveals itself.
Is there a limit to how far the scroll wheel will go when in perspective mode?
Not at the moment. I think there should be a limit to how close you can zoom and a warning, that you can't go any closer. It is not uncommon that users 'get stuck' trying to make the camera travel through the rotation center. (I have thought of a variety of ways, how to deal with a situation like that, but the first thing would be to set up a warning.)
Well... Taking small steps, I have the first travel-mode somehow working, but using it still reguires a bit of manual work, so not ready to publish it yet. :)
Last edit: Pete 2016-10-31
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi!
Hi for quite some time, I have been thinking of thoroughly renewing the view manipulation system of Art of Illusion. I like this style of modelling a lot, but over the years I have had to leave some projects on hold indefinitely because the view manipulation makes doing detailed work very difficult and I also know, that I'm not alone with that.
At first a few words about myself:
I have had the chance of watching the development of 3D-modelling for well over 20 years now. My first experiences were somewhere in the late 1980's with a WAX/VMS-system, that had things like "Boxer" and "Swans" to do basic boolean modelling and creating surfaces. Boy, was that slow!
I guess view manipulation was not considered to be an issue at those times. Now, since the year 2000 3D-modelling has been to me an essential part of making my living as a mechanics engineer. In that world a fluent and intuitive view manipulation system is a must. If the behaviour of view manipulation is not intuitive, it breaks the flow, when you are trying to concentrate on the details of your design and that software simpy has no future in the business.
Now, what I'd like to do is to offer my learnings out, to bring the view manipulation of AoI into the level where it deserves to be: To have professional level detailed modelling happen effortlessly. Sadly, what I have seen over the years is, that these things are hard to explain in writing, without the hands-on experience on it, so I'm afraid I'll need to do a lot of the work myself. Let's see how it works out. I know there are areas in there, that are unknown to me so far and I don't have much official education in software development. Most of the practical stuff I have learned about writing Java code happened by hacking AoI.
So to the business (current state):
I'm not going into the details of the current state of things. Let's just say, that it is a combination of different ideas, that do not work very well together. I can even see some of my own inputs in there. Also, a few years ago, I was trying to build a plugin for view manipulation but eventually it turned out, that some things are so deep, that a plugin can not respond to the user's commads quickly enough (if at all) to produce consistent behaviour.
The good thing, that I found out, is that the mathematical code behind the system is well capable of anything needed and also there are some features to the current system, that I like even better than in the engineering tools that I have used.
Then to the goals:
What I'd suggest is, that there would be two basic modes or mode sets to the view manipulation, Model and Explore.
The Model-mode is designed for doing either detailed modelling of objects or arranging scenes. It should be adaptive to the size of the current work and should be able to switch between parallel and perspective viewing with the adaptivity included. The Explore-mode could only produce perspective viewing as it is meant for travelling inside the model space. The Explore-mode could be used for example to design camera drives for animation.
The Model-mode should probably be split into two sub-modes, that could be called 3D and Landcape.
The 3D mode (And trust me, this is the way a serious 3D-modeller wants it!) would be one without a preferred up-direction. The "up" is always the up of your screen an you can turn the view into any direction you need to from your current orientation. The rotation center (or your point of focus) stays where it is while you rotate and moves with the view, when you move the view, so that it always is in the center of the view. The 'drawing plane' (or 'Screen' in AoI terms) is always fixed to the rotation center.
The Landscape mode would basically be a tilt locked version of the 3D, actually quite close the current behaviour, having the Y as the preferred 'up' and some limits to things like, how far forward or back you can tilt the view. Eventually it should have the option to select the 'preferred up' freely, but at this point I'd give that a lower priority.
The Explore modes come currently in many forms in different software packages. They may be called things like 'Walk', 'Drive', 'Fly (airplane), 'Fly (space ship)'. Some even come with game-engine-like real time animation systems.
As the starting point I'd introduce something with resemblence to the Google Earth approach: You can place yourself into the model and then point or scroll-wheel, where you'd like to go next. In this mode the rotation center would be the camera itself. The viewing angle could be a bit wider than in modelling modes and preferably user-adjustable. (AoI CAN do that, though right now I'm not sure how it happens.)
The first steps:
As the first thing I'd add a View menu to the scene window. There would not be much left in the Scene menu, but these are separate areas to deal with and view manipulation needs more options.
Next I'd probably add animations to the 'quick-moves', like switching between viewing directions. That has been pretty standard in engineering tools for over ten years already and I have an animation module ready in the plugin attempt. There are some minor issues to fix, but most of the time it works quite nicely.
And yet another thing: If this thing takes off properly, at some point it might become tempting to add automated (say game-camera-like features) to the system. For any automation there is one rule, that must be obeyed without exception: The user has to have the choice to use it or not. This actually goes with the animated moves as well.
Then some practical points:
Unfortunately view manipulation is not just one file or one module in the code. It is scattered all over the place into parts that interact with each other.
Working in that environment will require changes into a number of files and it will take a lot of time, fixing one issue at the time, while not forgetting the future goals. This also means that more information needs to be passed between different parts of the software than before. New variables need to be defined, old ones may be removed... Possibly some kind of a master list or master object could be created to watch over the actions. (I had something like that in the plugin. If such a master could be created, it could -- at least theoretically -- become a receptacle for plugins, that would add new features to the viewmanipulation system.)
All the above could also mean, that some plugins may stop working until somebody reconfigures them. However, to my mind, the priority of those can not be very high in the bigger picture.
Finally:
Any further thoughts? I know, I may be looking deep into the future with some of these ideas, but hey: Man did visit the moon and came back!
I'm now starting to take my first steps in the wonderland of GitHub, trying to add the View menu. Let's see, how badly I'll mess things up, ;)
BR
-Pete-
Last edit: Pete 2016-10-18
Thanks for the detailed description. It's good to hear from someone who uses similar systems extensively.
I think that I understand pretty much what you mean, especially in regard to the Model Modes. Very clearly explained.
Not a lot of time this morning, but I can fill in one gap:
Field Of View angle is a property of the camera. As things are currently arranged, this means that it is only user editable if:
This certainly seems that it could be improved. The angle is fit to the height of the veiwport, and the width is proportionate.
That's right.
The view cameras do not have that property. Instead, there is a fixed relation between the perspective strength and the parallel mode, so a larger view has a wider angle. That actually works very nicely as the user's perception of the perspective stays the same regardless of the size of the view. On a scene camera the perspective strength depends on the FOV and image is scaled along witn the view height.
But:
This is a bit of a different case.
Working on the plugin I acccidentally bumped into somethig, that actually changed the perpective stength of the editing views. A long matrix calculation that prpbably was not even meant to do that and definitely was not supposed to be used. -- But figuring out how that worked (and having a look at what FOV does in the SceneCamera) would lead to creating a user setting for perpective strength. Usually that option is available to users and the comfortable (natural) setting basically depends on the distance between your eyes and the display.
Anyway: I pushed my first changes to GitHub, but it seems, that I did not quite manage follow the rules/practices. In that case just bounce it back and I'll try again. :)
BTW. Let's not let this delay the release of 3.0.3 -- maybe 3.1 could be the next possible target for it. -- It seems that I had almost everything needed (except for the Explore mode) in the plugin at least in some kind of a form.
-P-
For the overall project, I agree. Many of these changes are likely to require multiple rounds of testing and feedback, so I'd prefer to defer them for another release.
Just moving the view options to their own menu, as you already have, is small enough that I'm not going to delay that bit. I'm going to add a few notes to your PR on github, to help you avoid some potential issues down the road.
Thanks.
I started to work on adding the view animation module and that requires an addition to the preferences table (whether to use the animations or not). So far no problems but I found out, that the artofillusion_en.properties is an empty file in the GitHub master. Any idea, what that is about? Can I just replace that with another one? By some miracle the build still seems to know the English translations except for the addition.
English translations are actually in the default
artofillusion.propertiesfile, without a language code. Its the fallback file if there is no translation in the prefered language.Oops... I knew that, but somehow got confused. -- But hey that's me, what would you expect! ;)
Hi, re. View Manipulation.
I would like to see the view's working independently, as presently if I set up a view
in " Left " then change the view in " Top " the " Left " view changes also.
A handy thing would be to be able to save the current view, eg if I view an
object in " Left " view then orbit around it to get just the right angle, the view
changes to " Other ". Something like " save current view as new camera "
or " lock view position " would be very useful.
regards,
chris w.
Hi! -- Thanks for the input.
I'm not sure if Iquite follow, but the views are supposed to be independent of each other.
You can always return the view to any of the presets by picking for example "Left" from the dropdown menu, (just where it says "Other" after rotating). "Other" simply means that the orientation does not match with any of the presets, Front, Back, Left, Right....
I think that could be implemented as user presets that would capture the position, orientation ad scale of the view. Those could be added to the preset list. For the scene window that should be relatively easy but for object editors, I think, those would have to be saved individually for each object. There might be a couple of different ways of doing that. I'll put the idea into the 'thinking cap' -- There's a lot to do before that. :)
I was just working on zoom function of the perspective viewing mode.
As a by product I discovered, that the distToScreen parameter of Camera class actually controls the perpective strength of the view. I was wondering why changing that was dephrecated. Now I may have a hunch... Here is a demo video where the camera (= the viewing point) moves along as the parameter is changing.
I will definitely add using this information to my to-do list. This would make a pretty cool feature for personalizing the software. :)
Last edit: Pete 2016-10-21
possibly relevant? especially the first couple of paragraphs about the 'why.'
Interesting idea. I certainly can see cases where it'd be useful. Then think it would be most benefiacial if it would affect both the preview rendering and final image rendering. -- Actually there are some other things too where the SceneCamera (or Camera) and the render engines could interact a bit more.
But for now, clearly a different project. Say, that'd be 'optical' whereas, what I'm on, is more or less 'mechanical'. :)
I meant that the article may give some insights into why the distToScreen element was created in the first place. From you video, the distortion as you vary the parameter seems a lot like what you would get from adding some barrel to th rendered image....
Actually no. It's a pure pinhole perspective. Though you are right that somehow the human perception may suggest that there would be a bit of barrel in it. I had to make another demo to check... The lines stay absolutely straight in this one. (The extra wide FOV somehow messes up drawing the grid.)
The barrel distortion taken to the extreme would of course be the fish-eye perspective. http://www.friendlyskies.net/aoiforum/viewtopic.php?id=1896
EDIT: Changed the attached video.
Last edit: Pete 2016-10-25
A prototype for testing: http://www.kuukahvila.com/peteihis/AOI/development/artofillusion/
Features:
-- These are available both on Scene and Object windows
-- Currently the Landscape mode does not allow tilting
-- whether to use animations or not and
-- set the maximum duration of animations (time varies according to need)
-- Unfortunately you need to restart AoI for the preferences to become effective.
Some glitces:
More features to be expexted:
Warnings:
The forthcoming git push (or two) will be pretty massive. At the moment over 20 files have been edited. It may be possible to split that in half, but in many cases the changes in files are interconnected. At the moment it looks that I'd better to move a thing or two into different places, but nothing major before starting to add the still missing features.
Have fun :)
-- OH! And please post back if you see anything really weird happening!
Last edit: Pete 2016-10-28
Sounds cool. I'll do some checking in the next day or so. Please do not hesitate to create a pull request - github has a handy interface for developers to discuss and comment right in the code, and you can continue updating the branch as testing and feedback comes in.
Please don't try to split up a pull request if the changes do not make logical sense without each other, its easier to track changes that are commited as a whole. What you have posted to github is not all that big a change, anyway. Only 9 files touched so far, and most of that seems to be fairly simple updates.
Done that. Shows 27 files now.
A strange bug appears on the Object Editors (see picture - low right). As soon as I touch any of the tools or the controls of that view or click on the view, the view is corrected. This is related to setting the view to Perspective, but I don't know how. It couldn't seem to be able to repeat this on th eother views and if I use a .bat-file to launch AoI the bug does not happen.
Can anybody repeat that?
Edit 1: Another strange bug: ....
Edit 2: ... that is no longer. :)
-P-
Last edit: Pete 2016-10-29
Liking it so far. The modes make intuitive sense once you've played with them a bit. I do have a few thoughts:
I've also got a feature request:
I primarily see the above as useful when tweaking Scene Cameras for rendering. If you have questions/thoughts on the interface, let me know.
I may drop in to leave some code comments tomorrow on github, but now I need to sleep.
I seem to remember that and as I recall the issue was a bit different for both of us. I have been wondering if it would make any sense to have a "cameraShake" method or something like that just to use the views so much, that they'd be updated. repaint(), updateImage, viewChange() etc. seem to have no effect in those situations.
If you find out, let me know.
Yes, I think that might be a good idea in the modelling modes as well. The (comin) traveling modes are supposed to work that way by default. I feel uncomfortable about severing the rotation center from the camera z-axis even temporarily. That's just the thing, that I have been trying to get rid of. But how about cacheing a set of previous view settings and having a key combination to reverse back to them?
That might be useful, but the scroll wheel action then needs some more work. Somehow it should be decided, what makes one continuous scroll as now each click of the scroll wheel is handled as a separate move. (But the scroll wheel would need that system anyway for other reasons.)
I'll put that into the thinking cap.
Last edit: Pete 2016-10-29
RE: disconect of z-axis and rotation point:
Now that I've slept on it, and thought it through, the rotation point should be reset once the user releases the mouse from pan mode.
I've also managed to reproduce my glitch. It seems to happen when clicking to center when in perspective view. Not every time, and not any pattern that I can yet nail down.
And, a specific bug: "Frame selection with camera" and "Frame scene with camera" should only affect the view that is 'active,' that is, that you have most recently:
As it currently stands, these commands adjust all veiws that are not set to a scene camera.
That's somethig, I regard as an AI feature, where you can easily go wrong. It sounds like a cool idea, but what if you have built an environment like a park or a city and all of the sudden your rotation center jumps into the horizon? Not so cool, I guess... There should the at least be a switch to turn it off.
Moves the rotation center along with the camera, keeping the distance to the camera same. I think that should be the default for the Pan and also the Travel modes.
Tried that, but did not have it happen.
That is not really a bug but an intentional feature. I think there are some kind of historical reasons behind that but I agree, that they should affect just the active view. That should be easy to fix. The
getView()of editing windows returns the active view.I'm thinking of replacing the Frame-commands with new ones anyway. The
frameBox()inViewerCanvas, which does the work for those, is built in such a way that making it animation-capable is not very simple. Have just been schetching a plan in my head, how to do that. :)Sorry, I'd somehow got the impression that you had already been tweaking the "Frame" commands...
Tracking some of the glitches down is one reason that I think having a way to see the current rotation center in other views would be handy...
When I get the glitch I'm referring to, it almost seems as if the click is not intercepted at the actual object.... I end up sliding off into the sunset, way away to one side (switching to parallel has me hundreds of units away from center. I'll do more testing.
Is there a limit to how far the scroll wheel will go when in perspective mode?
So.... Releasing after a pan move would set the rotation center to 'center of view' at the same distance it was before the pan? Sounds reasonable....
I did mention that as a plan, and the plugin had some kind of a work-around to it.
That and a few other things. I had a look at the
drawLine() andrenderLine()methods, but though they are made public, they need to be called from inside theupdateImagemethod, to leave anything visible on the screen.I think it would take something like
drawTemporaryGraphics()that would take care of visualizing, what ever was considered necessary. -- And again, a tag in the Preferences if to show or not.I still have not had that happen to me. There is a somehow similar problem in the VM plugin, though and I never found out what exactly caused it. I suspect something like the
viewChanged()driving the camera move to loop... But if it happens randomly, it may be hard to find. Let's hope it reveals itself.Not at the moment. I think there should be a limit to how close you can zoom and a warning, that you can't go any closer. It is not uncommon that users 'get stuck' trying to make the camera travel through the rotation center. (I have thought of a variety of ways, how to deal with a situation like that, but the first thing would be to set up a warning.)
Well... Taking small steps, I have the first travel-mode somehow working, but using it still reguires a bit of manual work, so not ready to publish it yet. :)
Last edit: Pete 2016-10-31
Perhaps EditingTool.drawOverlay() is what you're looking for?