On 3/30/07, MenTaLguY <mental@...3...> wrote:

• One, we really just want the 3d box as a framework for whatever drawing we're doing. Boxes are great here.

• Alternately, we want just the VPs and resulting perspective grid for the sake of drawing features in perspective "freehand". For that purpose, a box is just in the way.

What exactly do you mean by "drawing in the perspective"? I think any kind of drawing in 3D starts with defining the box that your object will be inscribed into. Without the box, you cannot really ensure your object is in a correct perspective.

Also, while I don't think boxes are a bad idea, I'm less comfortable with the idea of adding more 3d primitives -- there's a lot of potential for scope creep. Where do we stop, exactly? Should we support lighting?

Of course not. No attempt to render anything except the _shapes_ of the 3D objects. Colors, lighting, shading etc. is entirely the responsibility of the artist - all parts of 3D objects remain regular paths that can be styled, cloned, masked, applied path effects, etc. all without losing the 3D editability of their parent object.

Import of arbitrary triangle meshes? Import of color and finish (e.g. diffuse versus specular) information? Mesh editing?

No, no, and no. The important thing to understand about this tool is this: we are not making another 3D editor. There are already lots of them, and we won't be able to come up with anything really new and inventive. Instead, we are making a tool in a 2D vector editor aiming to help 2D artists to quickly and easily produce 2D art that gives a believable impression of 3D. No more, no less. That seems to be a sadly neglected area, and I think we'll be able to do something quite novel if we concentrate on it.

One consequence of this approach is: there won't be really any 3D objects stored in the drawing. I don't think we'll store, for example, 3D coordinates of all corners of a box. Instead we will have 2D objects which just obey certain rules designed with the goal of 3D believability (but not necessarily absolute correctness). Some of these 2D objects can be mapped to orthogonal 3D boxes; some (e.g. those with skewed perspective) cannot. The ultimate goal is to make the 3D functionality as helpful as possible and yet as transparent as possible, so that it does not require any complex setup, any preliminary 3D layout planning, or any unnecessary limitations or complications of the regular drawing process. You just pick the tool and start _drawing_, not "building the 3D world" as with a typical 3D application.

Camera focal length settings?

Also no. This one in particular is illustrative of the approach we are taking. In a regular 3D app, you indeed change the focal length, and the perspective - vanishing points - of your view changes accordingly. In our tool, you can achieve the same but from the other end: you simply drag the vanishing point where you want it to be, and this affects the perspective of the 3D objects, essentially giving you the equivalent of switching from wide angle to tele or back.

On 3/30/07, Dave & Ann Marie Barry <VeryBarry@...714...> wrote:

Please help me out here if I don't understand. (I'm an engineer not an artist) You have a 2D drawing/graphics application -> "Inkscape". To assist you in drawing 2D with depth (quasi third dimension) you want a tool to draw and modified the reference lines easily so you can get on with the artistic part.

Exactly.

This seems straight forward enough. You'll need to store this new class data during use (until no longer required). Has anyone started the class development? Why don't we create and implement a simple frame work and see how it works. Then we can develop it more after an initial evaluation.

Currently we are in preparatory stage. Implementation has not started yet. The current plans are outlined here:

http://www.rzuser.uni-heidelberg.de/~malbert/

Dave & Ann Marie Barry schrieb:

Excellent. I guess I can start deriving equations and methods for implementing those actions and try them out.

That's what I was also planning to do in the next week or two. Unfortunately, I will be really busy for the next few weeks due to the completion of my Diplom thesis. But I'm sure I won't be able to resist the temptation. :)

BTW, thanks for offering to help, Dave! Much appreciated. I must confess, however, that figuring out the maths and writing the fundamental classes is part of why this project fascinates me so much (apart from the GUI aspect), so I'd really like to work on that, too. But I reckon that there is enough to do for two people - just don't make me redundant, please. ;) Furthermore, exchanging and discussing ideas may be very helpful. The most important thing, though, is IMHO that the design should be carefully adapted to the way we want the tool to eventually work. I only made a few drafts in the last days, but I hit upon a couple of points where I considered it worthwile to write a class in a slightly different way than would be most suitable for, say, a general purpose library. I think this can often facilitate interaction with the GUI. I can say more about that as soon as I have the time to really think about the class design in detail.

A general question: Just in case I should really be accepted to work on this for SoC, to which extent is it 'legal' to work together with other people? May that be a problem with the regulations?

Cheers, Max

On Sun, Apr 01, 2007 at 10:02:32AM -0400, Dave & Ann Marie Barry wrote:

Also, I have a 2D matrix multiplication function from some years back. It may be helpful. Also, I have been working on a program to graph real and complex data overlaid together. So there may be some stuff there we can use. It includes classes for 2D graphing coordinates, a complex number class and operator overloads.

Make sure to also check out lib2geom, which is planned to be added to Inkscape and which I believe also has code for matrix math such as this.

Bryce

On Sun, Apr 01, 2007 at 02:58:09PM +0200, Maximilian Albert wrote:

A general question: Just in case I should really be accepted to work on this for SoC, to which extent is it 'legal' to work together with other people? May that be a problem with the regulations?

In fact, the GSoC program's purpose is to help students gain experience working with others on Open Source projects, so not only is it legal to work together with other people, but it's expected. In fact, the questionare that mentors fill out at the end of the year asks exactly this.

Culturally, our school systems make a point about students *not* working together, unless specially directed. So by default, as students we're trained to NOT work together.

But in open source projects (and also in the real world in general), much more is achieved by working together and collaborating than if we each did our own thing individually.

However, working together is challenging, especially when you haven't had much experience with it before. You have to learn how to discuss ideas and plans with others and find good solutions without getting into heated arguments, you must learn how to manage dependencies on other people (who may be unreliable), you must learn to step back when others can do it better, or step forward when you know the work must be done and you can do it. You learn how to become an effective member of a team, and how making your team successful makes you successful as well.

Sometimes the best way to be a good teammember is to look at what others on the team are passionate about, and just let them immerse themselves in that work, why you focus on areas they're less interested in. This can be tough since often you too are very interested in those exciting parts. :-)

Hope this helps, Bryce