PureBasic Forums - English

Hi,

I'm annoucing the beginning of a new project called raafal.

A free and open source, cross-platform 3d application framework intended for professional work, and an alternative to blender.

Internal code will be mostly inspired from Blender concepts and it will use open source libraries from pixar, ilm, disney, sony, etc.. but the UI and ergonomic will be completely different from blender, closer to Softimage|XSI. The main framework and UI will be coded entierly in PureBasic (and possibly a lot more).

No rush though, I'm aware this will be a several years if not decades project.

This project is the result of several years of frustration from the behavior of some commercial dcc tools companies such as Autodesk.

PureBasic experts and 3d developpers experts are welcome.

This project is sponsored by my company, radfac. I've been R&D engineer and 3d technical director for more than 15 years.

Project home page will be at:

http://www.raafal.org

Several mailing lists are already available at:

http://raafal.org/mailman/listinfo

Thanks for your attention.

Cheers,
Guy.

Some news:

I've been busy (during my little spare time these days) refactoring the entire GUI code with the new features (Module,Runtime,etc..).

The GUI layout system is now finished. It's a classical 'viewport' system, splittable (horizontally, vertically or both). The viewport headers allows to choose which 'widget' to display (eplorer,log,3d view,etc..) and can be hidden.

Each viewport can have several 'tabs' (or widgets), be maximized(M), closed(X) and split(V/H/Q). Each viewport can be defined as a 'maximize group' which means once this viewport is split, viewport children will only be maximized in this parent viewport.

For now this layout system is textual only (no icon).

I now have to work on the 'widgets' and the 'controls'.



Cheers,
Guy.

Hello,

On the french forum we are discussing about the choice between having one Canvas for the all Window, or having one Canvas per 'viewport'.

Albeit Fred is advising for having one Canvas per viewport, for now I've choosen to have one Canvas for the all Window because of global resize (either from the Window resize, or a splitter resize which may trigger the resize of many child viewports), which seems to me more efficient with one Canvas. (I know, Fred is always right. But.. )

But I have a strong PC config, with a GForce Titan card, so perhaps I don't really see the difference.

Here is a little exe for you to test: raafal.gui.20130829.rar (Windows/x64)

Feel free to split and re-split the viewports and test the GUI speed, splitters resizing, etc.. I'm interrested to have your input (and your config description). On my side the speed seems to be correct.

(V,H,Q to split, M to maximize, ALT+M to create a 'Maximize Group' then split it and maximize a child Viewport to see the effect, X to close. The 'o' top left is used to toggle the header. Once hidden move your mouse to the viewport top left or top right to show it again. The 'Tabs' don't work yet).

Don't pay too much attention to the actual features, but on the speed of resizing Viewports, that's what I'm interrested for now.

No problems and fast.

Windows 7 (6.1.7601) 64 bit Service Pack 1
Total physical memory: 12.581.012 MB
Free physical memory : 6.282.536 MB
Intel(R) Core(TM) i7 CPU 950 @ 3.07GHz, 3087 MHz, 8 logical cores
Desktop is 1920 x 1200 x 32 bpp @ 59 Hz
Multimedia Timer resolution: 0.001 seconds
High Performance Counter resolution: 0.0000003317 seconds

OpenGL Renderer: GeForce GTX 560 Ti/PCIe/SSE2
OpenGL Vendor : NVIDIA Corporation
OpenGL Version : 4.3.0
OpenGL is Hardware Accelerated
VSync is supported
VSync is enabled, unlocked
Max texture size is 16384 x 16384
Max num. of samples for MSAA: 16

Thanks for your input luis.

No problems and fast.
Test Small PC

Intel Core2 Duo CPU P8600 2.40 Ghz
4,00 GB RAM
NVidia GeForce 9600M GT 512 Mo
Windows 7 64 Bits

Nice job grabiller

Thanks falsam )

Core i3
Windows 7-64
4Gb RAM
2 Core (4)
No graphics card.
27" Monitor.
Under 75% load but still runs very fast. On any size of window.

(Bit of flicker whilst re-sizing the window.)

Thanks davido.
(very interresting with your config)

Regarding the flicker, I think it is unavoidable. I have it also (albeit just slightly and I guess it depends how fast the PC is able to redraw).

That said, I've checked several 'professional' applications (Modo, Softimage, Maya, etc..) they all exhibit flickering on main Window sizing so I guess it is something we have to live with it, at least on Window. Yet users of such application do not often resize the main Windows but almost always use the application maximized.

Works pretty smooth and almost no flickering on my config. By the way how do you minimise it? I'm working on my custom GUI and I get quite a bit of flicker (at least compared to your interface) when resizing the window [and the canvas].

grabiller wrote:Albeit Fred is advising for having one Canvas per viewport

You should heed Fred's advice as it is the correct decision to make.

Olby wrote:Works pretty smooth and almost no flickering on my config. By the way how do you minimise it? I'm working on my custom GUI and I get quite a bit of flicker (at least compared to your interface) when resizing the window [and the canvas].

Actually I'm doing nothing special but using only one Canvas per Window and only one StartDrawing() per update.
Inside the Canvas, I have no overlap between Viewports nor Controls (not yet shown in this exe), except for the Text.
For instance, I don't draw a huge Box as a background, each Viewport draws its own background, and only when necessary (it wont if a Widget is displayed for instance).

Kuron wrote:

grabiller wrote:Albeit Fred is advising for having one Canvas per viewport

You should heed Fred's advice as it is the correct decision to make.

This is arguable. Fred is correct in terms of resources used to draw the GUI, I now understand that.

But from another point of view, there are arguments why having only one Canvas makes sense.

On the french forum Fred is talking about the idea to have a StartDrawing() having an optional clipping rectangle argument (even if this feature is not planned yet).

With this addition, it could be the best of both 'worlds'. Having one Canvas, but using very few resources at the same time when updating (portions of) the GUI.

The choice between having one Canvas per Window or one Canvas per 'Viewport' is not that easy nor obvious to make.

Both ways have their advantages and issues.

Isn't it already possible with a canvas to only redraw the parts that need redrawing ?

wilbert wrote:Isn't it already possible with a canvas to only redraw the parts that need redrawing ?

Yes, this is exactly what I'm doing in my code.

But I think Fred was refering to the fact that a StartDrawing() is locking the all surface at the same time, even if we draw only on a small portion of it.

I've checked my CPU resources more in details:

With my Window full screen (1920x1200), with lot of split Viewports (24 Viewports displayed at the same time):

- When I move the higher level Splitter, which means all 24 Viewports are redrawn/resized, with my config (i7 x980 @ 3.2GHz/GForce Titan), my CPU takes ~10% (which is not negligeable for this config albeit having to redraw/resize 24 Canvas I'm not sure it would be more efficient).

- When I move the mouse over a group of V H Q M X to highlight them rapidly (which means I'm only updating a very small Canvas portion despite the near fullscreen blit of the internal Canvas image), the CPU goes down to ~1/~2%.

This confort me in the idea that even with a big Canvas surface, it is still relatively efficient to only radraw a small portion of a Canvas despite the fullscreen blit of the Canvas internal image.