GSOC2007 3D box tool - Revision history

Innovati: /* Project description and purpose of this Wiki */

2007-07-09T20:26:46Z

Project description and purpose of this Wiki

← Older revision		Revision as of 20:26, 9 July 2007
Line 61:		Line 61:

	Drawing with transparency, it's possible to create translucent boxes.It's difficult to express this in text form.My mail is in the list if someone is interested in discussing this.		Drawing with transparency, it's possible to create translucent boxes.It's difficult to express this in text form.My mail is in the list if someone is interested in discussing this.

			== Alternative ideas (innovati) ==
			What if the program extrudes the shape by default, but can also link 2 shapes and morph betwen them.

			Now, AFAIK SVG has no way to handle 3d objects, so upon export, the 3D shape would have to be interpreted as a series of 2D shapes....although perhaps the editable 3D shape can be stored within the SVG and read by inkscape when you re-open that image in inkscape, ensuring both standard SVG viewing for the web, as well as lossless editing.

Skypainter at 18:02, 7 May 2007

2007-05-07T18:02:18Z

← Older revision		Revision as of 18:02, 7 May 2007
Line 12:		Line 12:

	If you have ideas concerning the underlying maths, algorithms, class design, etc., this is the place to share it. Please bear in mind, however, that we are designing a tool for a 2D graphics application. This means that we are going to write a tool that <i>behaves</i> like it manipulates 3D objects, but most of the time the complete 3D information for the boxes and their corners (in particular, the precise value of the z-coordinate) won't be available. Instead, we will often need to fall back to information gained from the 2D canvas constellation of the corners and vanishing points. Thus, it is sometimes necessary to make approximations which lead to small deviations from the 'true' behaviour. Our aim is to preserve the right 'feeling' and to make these deviations as invisible as possible.		If you have ideas concerning the underlying maths, algorithms, class design, etc., this is the place to share it. Please bear in mind, however, that we are designing a tool for a 2D graphics application. This means that we are going to write a tool that <i>behaves</i> like it manipulates 3D objects, but most of the time the complete 3D information for the boxes and their corners (in particular, the precise value of the z-coordinate) won't be available. Instead, we will often need to fall back to information gained from the 2D canvas constellation of the corners and vanishing points. Thus, it is sometimes necessary to make approximations which lead to small deviations from the 'true' behaviour. Our aim is to preserve the right 'feeling' and to make these deviations as invisible as possible.

			== One opinion (Jose Hevia) ==

			Making a tool that behaves as 3d in 2d is, IMHO, impossible or severely limited, I have some experience trying exactly this, and believe that a model in some kind of 3d space is needed. Something as simple as a 2D layout that represents the plant is in itself 3d space.

			Making use of a known model let us use the math that is already there for perspective projections, there is no need for creating any new set of rules that are complex to manage when models evolve in complexity.

			E.g It's possible to use traditional technical drawings rules for drawing in the computer, using fugue points for every set op pararell lines and find intersection for every segment you draw.

			Well, you just need to create a new point, choose a fugue point(keybindings?) draw a segment.Fugue points need to be movile. Then you have two points. You draw new points using the same technical way, when two lines cross, you create two segments. Now just make it posible to select manually the segments that are ocluded and remove it.

			As there is no 3d model of it there is no way the computer knows how to do this automatically, and is only valid for a unique view. You have a model that only works with a couple of fugue points, that is difficult to maintain and very complex UI code slow to prove in something as huge as Inkscape codebase.

			== Alternative(Jose Hevia) ==

			Create a plant 3d model (extruded from 2d, from plant to top).

			A pair of fugue points are needed, one for every orthogonal directions. Now it's possible to extract the viewer direction.(*)
			A height of the horizon (view height),and extrusion height.(**)
			E.g:

			- Draw a path(conventional one) as the plant 2d model.
			- Use the path to draw the plant as a polygon:
			+Create 3d coordinates with height zero.
			+Apply perspective matrix, with the info from ()(*)

			- If extrusion height > horizon draw top polygon:
			+Create 3d coordinates with height top.
			+Apply perspective matrix, with the info from ()(*)

			- Create and draw faces:
			+Calculate path farther point to observer.
			+calculate path nearest point to observer.
			for farthest point to nearest point create left faces:
			+calculate two points from path with top height.
			+calculate two points from with zero height.
			+draw four points polygon.
			for farthest point to nearest point create right faces:
			+calculate two points from path with top height.
			+calculate two points from with zero height.
			+draw four points polygon.

			(+++)Caution:This code only works well if complex hull(path)==path, as happends with a rectangle. If not , it's necessary to order faces better.

			- If extrusion height < horizon draw top polygon:
			+Create 3d coordinates with height top.
			+Apply perspective matrix, with the info from ()(*)

			Drawing with transparency, it's possible to create translucent boxes.It's difficult to express this in text form.My mail is in the list if someone is interested in discussing this.

Cilix: /* Project description and purpose of this Wiki */

2007-05-07T07:01:47Z

Project description and purpose of this Wiki

← Older revision		Revision as of 07:01, 7 May 2007
Line 3:		Line 3:
	Information on the project can be found at the [http://www.rzuser.uni-heidelberg.de/~malbert accompanying website]. Currently provided are a description of the intended functionality and a collection of further ideas (beyond the scope of GSoC). Implementation-related details will follow soon.		Information on the project can be found at the [http://www.rzuser.uni-heidelberg.de/~malbert accompanying website]. Currently provided are a description of the intended functionality and a collection of further ideas (beyond the scope of GSoC). Implementation-related details will follow soon.

	This Wiki on the other hand is intended to be a kind of 'bazaar of ideas'. People who are interested are warmly invited to share their thoughts. Feel free to add any ideas, ranging from the general functionality to implementation~~-related~~ details. I started out with these two categories below, but please add further ones where appropriate.		This Wiki on the other hand is intended to be a kind of 'bazaar of ideas'. People who are interested are warmly invited to share their thoughts. Feel free to add any ideas, ranging from the general functionality to implementation details. I started out with these two categories below, but please add further ones where appropriate.

	== Feature proposals ==		== Feature proposals ==
Line 11:		Line 11:
	== Implementation details ==		== Implementation details ==

	If you have ideas concerning the underlying maths, algorithms, class design, etc., this is the place to share it. Please bear in mind, however, that we are designing a tool for a 2D graphics application. This means that we are going to write a tool that <i>behaves</i> like it manipulates 3D objects, but most of the time the 'complete' 3D information for the boxes and their corners (in particular, the precise value of the z-coordinate) won't be available. Instead, we will often need to fall back to information gained from the 2D canvas constellation of the corners and vanishing points. Thus, it is sometimes necessary to make approximations which lead to small deviations from the 'true' behaviour. Our aim is to preserve the right 'feeling' and to make these deviations as invisible as possible.		If you have ideas concerning the underlying maths, algorithms, class design, etc., this is the place to share it. Please bear in mind, however, that we are designing a tool for a 2D graphics application. This means that we are going to write a tool that <i>behaves</i> like it manipulates 3D objects, but most of the time the complete 3D information for the boxes and their corners (in particular, the precise value of the z-coordinate) won't be available. Instead, we will often need to fall back to information gained from the 2D canvas constellation of the corners and vanishing points. Thus, it is sometimes necessary to make approximations which lead to small deviations from the 'true' behaviour. Our aim is to preserve the right 'feeling' and to make these deviations as invisible as possible.

Cilix: Initial page (description of the purpose of this Wiki)

2007-05-07T06:58:11Z

Initial page (description of the purpose of this Wiki)

New page

= Project description and purpose of this Wiki =

Information on the project can be found at the [http://www.rzuser.uni-heidelberg.de/~malbert accompanying website]. Currently provided are a description of the intended functionality and a collection of further ideas (beyond the scope of GSoC). Implementation-related details will follow soon.

This Wiki on the other hand is intended to be a kind of 'bazaar of ideas'. People who are interested are warmly invited to share their thoughts. Feel free to add any ideas, ranging from the general functionality to implementation-related details. I started out with these two categories below, but please add further ones where appropriate.

== Feature proposals ==

Pretty self-explanatory.

== Implementation details ==

If you have ideas concerning the underlying maths, algorithms, class design, etc., this is the place to share it. Please bear in mind, however, that we are designing a tool for a 2D graphics application. This means that we are going to write a tool that <i>behaves</i> like it manipulates 3D objects, but most of the time the 'complete' 3D information for the boxes and their corners (in particular, the precise value of the z-coordinate) won't be available. Instead, we will often need to fall back to information gained from the 2D canvas constellation of the corners and vanishing points. Thus, it is sometimes necessary to make approximations which lead to small deviations from the 'true' behaviour. Our aim is to preserve the right 'feeling' and to make these deviations as invisible as possible.