PDA

View Full Version : gtk like 3d library


cygo
January 2nd, 2008, 03:29 PM
hi,
i don't know if this is already planned: a gtk like library that allows you to create e.g. 3d-buttons, so the surface of the cube sides does not necessarily have to be flat.
This would give a great effect when rotating the cube. If you stay at one workspace the 3d objects could be projected to a 2d texture so it wouldnt use too much computing time.

delfick
January 3rd, 2008, 02:26 AM
hello

this is out of the scope of compiz so I'm gonna move it to linux talk.

also, this thead http://forum.compiz-fusion.org/showthread.php?t=5783 already touches on it.

basically they're making composite aware gtk widgets so in a sense yes it is being made

:D

b0le
January 3rd, 2008, 05:48 AM
look at macslow.thepimp.net

SmSpillaz
January 3rd, 2008, 01:29 PM
Well, it's not really 3D widgets, but more or less gtk widgets being redirected offscreen and rendered with openGL (Which allows for fancy effects)

DJ Barney
August 12th, 2008, 02:54 PM
I had the same idea myself. Such a widget library could work with something that can capture window interaction in 3D space. I'm not sure if Compiz can do that, or if there are any plans to do it. It's more a move from being locked into 2D space by the window manager to complete 3D. Compiz does a damn good job of opening up the 2D experience and making things a bit more organic. Wobbly windows, and so on, although I'd like to see a complete out of the box (as think outside of) approach to the way we use GUI's. I think it's far too constraining being locked into this 2D view of everything. It's seen as cosmetic, but I suspect that freeing things up this way has more of an effect on work flow than might be imagined.

DJ Barney

b0le
August 12th, 2008, 03:07 PM
The problem is that windows are still 2d. Even if you draw 3d widget (say with clutter), the window itself is still only 2d, so when you rotate the cube the perspective will appear wrong. This could be partially resolved by having a method for the application to find out the orientation of the certain window (and hence be able to draw the widgets correctly), however, I am sure that this wouldn't work to well while the orientation is changing (from say rotating cube, or rotating a window with freewins)

EDIT: also, buttons wouldn't stick past the windows, they would only _appear_ to stick out until the edge of the window (where things would look extremely wrong...). Then a button wouldn't appear to stick past the edge of the window, even though it should.

Although if all you want is "fake" 3d (fake in the sense that rotating the cube will cause perspective issues), then that is (afaik) already possible with clutter

DJ Barney
August 12th, 2008, 03:33 PM
The problem is that windows are still 2d.

Yes, exactly. Hence the idea for a 3D model widget library. The normal window controls would be replaced by 3D models of widgets in .OBJ, or some other format. You would be able to see the controls sticking out from the window when it's viewed from the side.

Even if you draw 3d widget (say with clutter), the window itself is still only 2d, so when you rotate the cube the perspective will appear wrong.

Yes, 20th Century widgets were based on a pseudo 3D style using 2D graphics shadow offsets. Usually based on a light source coming from the North West (top left). True 3D widgets would, of course, shadow depending on where the light source currently is in the 3D scene.

This could be partially resolved by having a method for the application to find out the orientation of the certain window (and hence be able to draw the widgets correctly), however, I am sure that this wouldn't work to well while the orientation is changing (from say rotating cube, or rotating a window with freewins)

I think you're reinventing the wheel. It's been possible to calculate dynamic shadows for a while using OpenGL.

EDIT: also, buttons wouldn't stick past the windows, they would only _appear_ to stick out until the edge of the window (where things would look extremely wrong...). Then a button wouldn't appear to stick past the edge of the window, even though it should.

If true 3D models then they would stick out.

Although if all you want is "fake" 3d (fake in the sense that rotating the cube will cause perspective issues), then that is (afaik) already possible with clutter

Interesting application ! :D That's the kind of thing I'm thinking of but it doesn't have a 3D model widget set or a true 3D scene.

DJ Barney

b0le
August 12th, 2008, 03:46 PM
My point was that unless compiz draws the widgets (which seems like a bad idea...) then it is (afaik) impossible to get true 3d effect. No matter if you use models, or a 3d library, the window is still 2d, and if it is drawn by anything (apart from compiz), it will appear 2d when you rotate the window.

Another option (possibly what you meant) would be to make the windows actual 3d objects, then you just make a 400x400x32 voxel 'window' (instead of a 400x400 pixel window) and 'draw' in 3d.

If true 3D models then they would stick out.If the models were drawn by compiz they would stick out.

SmSpillaz
August 17th, 2008, 03:44 PM
Or to better explain b0le's point through an analygy:

Think of your 3D game that is fullscreen or in a window. Now picture that window as a television screen. Doesn't matter which way you view the image, you still see the same thing, because the same pixels are always used. Same thing applies to compiz. We just get the pixels, not the object itself.

DJ Barney
August 17th, 2008, 07:01 PM
So you're both saying there is a fundamental gap between widget rendering and compiz ? Compiz would only ever get a 2D render of the screen ?

So how would one go about doing it ? Would it require deeper coding down to the X level of the GUI ? So that widget elements can be rendered as 3D objects ?

SmSpillaz
August 18th, 2008, 12:35 AM
Let's just say you would have to throw out the millions of lines of code that is the GLX extension and start over.

DJ Barney
August 18th, 2008, 01:25 AM
Oh COME ON ! To render a 3D widget ? Obviously OpenGL would be used to DO THAT !

b0le
August 18th, 2008, 11:06 AM
It either requires compiz drawing the widgets (not a very good idea IMO)
OR
having windows as 3d objects (eg 400x400x32 voxels rather than 400x400 pixels), which you then 'draw' on, and compiz would then render that in 3d (since it is actually 3d it would do what you want) - which would require something a lot different than what X does...
OR
you could go away from pixels/voxels and do something entirely different (3d vector graphics) - which is even more different... (though seems like a good idea, especially when you consider zooming in on applications, it would at least get rid of that problem that pixels has)
OR
..?

Either way, to get 'true' 3d (as in, looks right when you are rotating the cube), it will require a lot of work.

SmSpillaz
August 19th, 2008, 09:09 AM
Oh COME ON ! To render a 3D widget ? Obviously OpenGL would be used to DO THAT !

Heh, you don't seem to understand how OpenGL works then =).

Every OGL app has it's own context. Compiz cannot touch this context, and the GL app renders to a framebuffer through DRI. The GL apps don't actually know that the cube is rotated, all compiz does it grab the buffer (in this case a window) it renders to and rotate that. Again, the analygy of looking at a TV screen. No matter which way you look at it, the image is the same =)

DJ Barney
August 19th, 2008, 11:47 AM
Oops, lost my coool there really :peace:

I could swear I'm sitting the other side of your tv screen SmSpillaz :cyclops:

I suspect a simple start could be made by rendering 3d title bars maybe using the 3d windows widget.

I discovered who the developer is on the 3d stuff through the irc channel so I'm gonna ask them.

b0le
August 19th, 2008, 12:48 PM
I suspect a simple start could be made by rendering 3d title bars maybe using the 3d windows widget.While it may be simpler to do that than getting apps to be 3d, it still would be a lot of work. At the moment the decorator renders to a pixmap, and sets appropriate properties on the window to indicate what part of the pixmap corresponds to what part of the window, which compiz (or the decoration plugin) then uses to draw the titlebars/border.

Changing this would require a new 3d-decoration plugin, and new decorators (or you could handle the whole lot in compiz and not have any decorators)

I'm not trying to say it isn't possible, or it is unfeasible, I am just highlighting that it still requires a lot of work

SmSpillaz
August 19th, 2008, 03:54 PM
Changing this would require a new 3d-decoration plugin, and new decorators (or you could handle the whole lot in compiz and not have any decorators)



You would have to do the whole lot in compiz.

There is nothing stopping you from making a compiz plugin where, apps can use compiz to draw their things instead of going straight to X/OGL :)

(I'm not making that btw :P)