raafal - un project de framework d'application 3d

[blendman]

De ce que j'en comprends, tu n'utilises aussi qu'un seul Canvas.

Oui, pour afficher le résultat, mais cela devrait être optimisé :
- afficher plusieurs canvas permettrait peut-être de gagner un peu de ressources. A tester.
- n'utiliser qu'un canvas ou ensemble de canvas de la taille de la zone de dessin (qui serait donc au max la surface du bureau). Là, le canvas fait la taille du document. Donc, je suis monté jusque 5000*5000 sans que ça ralentisse trop.

Petite question, pourquoi dessiner sur une image que tu re-dessine dans le canvas, alors qu'en dessinant dans le Canvas directement cela revient au même ?

En fait, je dessine d'abord sur une dalle (une petite image) pour pouvoir sauvegarder toutes les images si besoin (sauvegarde d'image). Puis, je redessine cette dalle sur le canvas.
Je ne redessine l'image complète (de la taille de l'area) sur le canvas que si je bouge la zone de la scrollarea.
J'ai testant en dessinant directement sur le canvas, mais je n'ai pas encore trouvé comment faire ça pour que ça fonctionne et que ce soit aussi optimisé.

Je veux dire par là, pourquoi ne pas utiliser un système de dalles virtuelles ? Cela reviendrai à ne dessiner dans le Canvas que dans la zone d'une 'dalle' à chaque fois.

qu'entends-tu par dalles virtuelles ?
J'ai besoin des images des dalles pour la sauvegarder du document, voire l'export ensuite en une seule grande image qui fait tout le document, et cela avec transparence.
Hors, le canvas n'a pas de transparence, je suis donc obligé de passé par des dalles-image et stocker les infos sur ces dalle-images.

Autre alternative si on va dans le sens de Fred, pourquoi pas un Canvas par dalle ? (mais c'est peut-être aventureux, là )

oui, j'y ai pensé. Je ferai un test quand je trouverai un peu de temps ^^.

Ce qu'on pourrait imaginer, c'est que StartDrawing() prenne une zone rectangulaire en parametre pour pouvoir travailler sur une portion reduite d'une image ou d'un canvas et optimiser ce genre d'operation (pour l'instant ce n'est pas prévu).

Du coup, ne pourrait-on pas imaginer une accélération hardware pour le Canvas ?

ce serait intéressant, mais il faudrait que ce soit en option ^^.
Voir un truc multithreadé

C'est vrai que je pourrai envisager d'utiliser un OpenWindowedScreen() (voire une surface OpenGL, carrément) et m'en servir pour toute l'UI. En même temps cela change considérablement la manière dont les Events sont gérés et dans ce cas on est obligé d'updater l'UI constamment, comme dans un jeu, ce qui n'est peut-être pas le plus efficace non plus pour une application 'normale' (les ressources risquent d'en prendre un coup, du coup).

Pas facile comme choix.

Je m'étais posé exactement la même question pour mon appli 2D.
En 2D, Djes m'avait expliqué qu'il valait mieux gérer ça avec un système de dalle (comme celui que j'ai essayé de mettre en place). Cela permettait de travailler sur des images immenses.
D'ailleurs, avec mon exemple, j'ai testé sur une image en 1000*1000 et en 5000*5000, c'est quasiment aussi rapide, donc, je doisêtre sur la bonne voie ^^. Il faudrait optimiser encore le système pour que ce soit nickel.

J'ai testé raafal chez moi, et ça prendre 48% de mon CPU lorsque je bouge les splitters. Mais c'est une petite machine (packardbell, AMD 1.4Ghz, ram 4Go, win8), je m'en sers surtout pour écrire mes Romans et faire un peu de bureautique, dessin (et de dev bien sûr ^^)

[grabiller]

@blendman
Merci pour ces précisions. Effectivement c'est une bonne approche pour des grandes surfaces. Je garde ça dans un coin de ma tête pour certains Widgets qu'il me faudra implémenter.


Sinon je voulais essayer avec les surfaces accélérées hardware en utilisant le OpenWindowedScreen() sur toute la surface de la fenêtre principale en lieu et place du CanvasGadget, mais j'ai tout de suite été confronté à un problème bloquant: Je n'ai pas trouvé le moyen de redimensionner explicitement cette surface pour qu'elle s'adapte à la fenêtre principale.

Il y a bien l'option 'AutoStretch' mais cela ne fait que 'stretcher' justement le contenu et ne redimensionne pas dans le sens où les coordonnées de dessin restent les même, c'est à dire que si au départ on a, par exemple, une dimension de 320x240 et qu'on redimensionne la fenêtre en 1920x1200, on dessine toujours sur une surface avec des coordonnées de 320x240. Un peu bizarre. (de plus cet 'AutoStretch' ne marche pas en DirectX11, et en OpenGL la surface n'est resizée qu'une fois qu'on a fini le redimensionnement de la fenêtre principale avec la souris, du coup, pas de 'stretch' temps réel).

Bref, cela me paraît mal barré d'utiliser un OpenWindowedScreen() en lieu et place d'un CanvasGadget.

Mais peut-être que j'ai loupé quelque chose ?

[Backup]

Sinon je voulais essayer avec les surfaces accélérées hardware en utilisant le OpenWindowedScreen() sur toute la surface de la fenêtre principale en lieu et place du CanvasGadget, mais j'ai tout de suite été confronté à un problème bloquant: Je n'ai pas trouvé le moyen de redimensionner explicitement cette surface pour qu'elle s'adapte à la fenêtre principale.

moi , je pensais que tu savais deja tout sous tes airs autum et accusateur (c'est de bonne guerre)

bon , c'est pourtant simple
tu close() le windowedScreen pour le refaire !

Code : Tout sélectionner

; Exemple de redimention de windowedScreen 
; Modifié par Dobro pour Garder la proportion 
; et eviter le mode AutoStrech



;***********************************************
;Titre  :*deplacement_redimention_windowedscreen_v5
;Auteur  : Dobro
;Date  :30/08/2013
;Heure  :23:48:36
;Version Purebasic :  PureBasic 5.11 (Windows - x86)
;Version de l'editeur :EPB V2.40
; Libairies necessaire : Aucune 
;***********************************************



InitSprite()

OpenWindow(0, 0, 0, 800, 600, "Bouton Gauche pour déplacer, Bouton droit pour redimensionner ;)", #PB_Window_ScreenCentered | #PB_Window_SystemMenu)

ContainerGadget(0, 50, 50, 100,100)
rez_x=100
rez_y=100

OpenWindowedScreen(GadgetID(0), 0, 0, rez_x, rez_y, #True, 0, 0)

balle.POINT\x = 25
balle\y = 50
vitesse.POINT\x = 2
vitesse\y = 1

Repeat
	event = WindowEvent()
	
	balle\x + vitesse\x
	balle\y + vitesse\y
	
	If balle\x < 5 Or balle\x > rez_x : vitesse\x = -vitesse\x : EndIf
	If balle\y < 5 Or balle\y > rez_y : vitesse\y = -vitesse\y : EndIf
	
	
	If event = #PB_Event_LeftClick ; #WM_LBUTTONUP
		ResizeGadget(0, WindowMouseX(0), WindowMouseY(0), #PB_Ignore, #PB_Ignore)
	EndIf
	
	If event = #PB_Event_RightClick ; #WM_RBUTTONUP
		ResizeGadget(0, #PB_Ignore, #PB_Ignore, WindowMouseX(0) - GadgetX(0), WindowMouseY(0) - GadgetY(0))
		CloseScreen()
		rez_x=WindowMouseX(0) - GadgetX(0)
		rez_y=WindowMouseY(0) - GadgetY(0)
		OpenWindowedScreen(GadgetID(0), 0, 0, WindowMouseX(0) - GadgetX(0), WindowMouseY(0) - GadgetY(0), #True, 0, 0)
	EndIf
	
	
	ClearScreen(0)
	If StartDrawing(ScreenOutput())
		Circle(balle\x, balle\y, 5, #Red)
	StopDrawing()
EndIf

FlipBuffers()


Until event = #PB_Event_CloseWindow

; 

; EPB

[grabiller]

Merci Dobro.

Effectivement en parcourant le forum je suis tombé sur plusieurs messages indiquant également cette approche.

Malheureusement elle est inutilisable, car sur une fenêtre entière et lors d'un resize on a un horrible flicking, 100 fois pire qu'avec la Canvas.

De plus, être obligé de fermer le Screen pour le ré-ouvrir (et réinitialiser tous les Sprites) me paraît être un non-sens, alors qu'en OpenGL il suffit normalement d'un simple glViewport (j'ai essayé mais ça ne marche pas avec le WindowedScreen, dommage).

Pour l'instant je teste un autre workaround, encore plus simple: au départ, même si la fenêtre principale ne remplit pas tout l'écran, j'appelle OpenWindowedScreen() avec la taille du Desktop (dans mon cas 1920x1200). Du coup je gère l'affichage en fonction des WindowWidth/Height et non des ScreenWidth/Height, les coordonnées restent correctes et je n'ai pas de flicking.

En voici un exemple: windowed_screen_resize_20130831.rar

Le fait que la surface soit plus grande que la fenêtre au départ n'est pas très grave puisque la plupart du temps, avec le genre d'application que je suis en train de développer, les utilisateurs s'en servent avec la fenêtre maximizée.

Mais au moins quand on restore/resize la fenêtre, ça fait un peu plus pro(pre) comme ça.

[grabiller]

Voici le source code basé sur l'exemple de PureBasic, ce sera plus utile que l'exe:

Code : Tout sélectionner

  If InitSprite() = 0
    MessageRequester("Error", "Can't open screen & sprite environment!", 0)
    End
  EndIf
  
  Procedure __OnSizeWindow()
    ClearScreen(RGB(0, 0, 200)) ; A blue background
    DisplaySprite(0, 10, 10)  ; Display our black box at the left-top corner
    DisplaySprite(0, WindowWidth(0) - 60, 10) ; Display our black box at the right-top corner
    FlipBuffers()
  EndProcedure
  
  ExamineDesktops()
  If OpenWindow(0, 0, 0, 320, 200, "A screen in a window...", #PB_Window_SystemMenu|#PB_Window_MinimizeGadget|#PB_Window_MaximizeGadget|#PB_Window_SizeGadget|#PB_Window_ScreenCentered)
    SetWindowColor(0,RGB(0,0,200)) 
    BindEvent( #PB_Event_SizeWindow, @__OnSizeWindow(), #PB_All, #PB_All, #PB_All )
    If OpenWindowedScreen(WindowID(0),0,0,DesktopWidth(0),DesktopHeight(0))
  
      CreateSprite(0, 50, 50) ; Create an empty sprite, will be whole black
        
      Repeat
        ; It's very important to process all the events remaining in the queue at each frame
        ;
        Repeat
          Event = WaitWindowEvent(10)
          
          If Event = #PB_Event_CloseWindow
            End
          EndIf
        Until Event = 0
        
        ClearScreen(RGB(0, 0, 200)) ; A blue background
        DisplaySprite(0, 10, 10)  ; Display our black box at the left-top corner
        DisplaySprite(0, WindowWidth(0) - 60, 10) ; Display our black box at the right-top corner
        FlipBuffers()
        
      ForEver
      
    Else
      MessageRequester("Error", "Can't open windowed screen!", 0)
    EndIf
  EndIf

[grabiller]

Bon, je viens juste de réaliser qu'on ne peut avoir qu'un seul WindowedScreen par application. Même pas par Window.. (Ou bien ai-je raté quelque chose ?)

Comme mon application doit supporter plusieurs fenêtres (multi-écrans), c'est complètement bloquant dans mon cas, et là, je ne vois aucun 'workaround' possible..

Je crois que je vais être obligé de me contenter du CanvasGadget pour l'instant, en attendant une éventuelle solution accélérée hardware dans PureBasic pour ce type d'application.

[blendman]

Merci pour ces précisions. Effectivement c'est une bonne approche pour des grandes surfaces.

J'essaierai de l'optimiser encore, en testant le multi canvas et autres bricoles.

je viens juste de réaliser qu'on ne peut avoir qu'un seul WindowedScreen par application. Même pas par Window.. (Ou bien ai-je raté quelque chose ?)

Effectivement, on ne peut pas ouvrir plusieurs screen dans la même application, c'est dommage ^^.

Va falloir rester avec ce bon vieux canvas ou coder un truc par toi-même en openGL, mais là, c'est un autre boulot.

[grabiller]

Oui je crois que pour l'instant je vais rester avec ce bon vieux Canvas en attendant mieux.

Je pourrai effectivement gérer moi-même l'OpenGL au niveau du fenêtrage mais comme je le réponds sur le forum anglais, du coup je perdrai tout le bénéfice des fonctionnalités de PureBasic en termes de fenêtrages, de gestion d'événements, de dessin, etc.. Et ça fait beaucoup. A ce moment là autant revenir au C/C++.

C'est frustrant parce que 'tout est là' dans PB et il ne manque juste que ce détail de (multi)fenêtrages avec surfaces accélérées matériellement pour pouvoir aller taquiner les applications 'pros'

[blendman]

C'est frustrant parce que 'tout est là' dans PB et il ne manque juste que ce détail de (multi)fenêtrages avec surfaces accélérées matériellement pour pouvoir aller taquiner les applications 'pros'

tu peux poster dans features request, s'il y a quelque chose que tu aimerais avoir

[grabiller]

C'est frustrant parce que 'tout est là' dans PB et il ne manque juste que ce détail de (multi)fenêtrages avec surfaces accélérées matériellement pour pouvoir aller taquiner les applications 'pros'

tu peux poster dans features request, s'il y a quelque chose que tu aimerais avoir

Oh mais je crois que Fred est bien au courant de ce qu'il me manque, on en a déjà discuté en privé.

Cela va dépendre de sa volonté, de son temps disponible, de ses priorités.

En attendant je vais essayer d'avancer sur le pathtracer où la GUI importe peu pour l'instant

[Backup]

En attendant je vais essayer d'avancer sur le pathtracer où la GUI importe peu pour l'instant

je suppose que tu as regardé cette autre approche du ray tracing (tres rapide )

http://forums.purebasic.com/english/vie ... 82#p423000

[grabiller]

En attendant je vais essayer d'avancer sur le pathtracer où la GUI importe peu pour l'instant

je suppose que tu as regardé cette autre approche du ray tracing (tres rapide )
http://forums.purebasic.com/english/vie ... 82#p423000

Je ne connaissais pas ton code. Sympa.

Il s'agit effectivement d'un 'simple' (je dis cela sans ironie ni mesquinerie) raytraceur, qui ne gère que l'illumination directe, et non la Global Illumination (la lumière indirecte), ce qui permet un calcul effectivement nettement plus rapide que tout autre technique de raytracing gérant la GI. De plus, ton raytraceur ne gère pas l'anti-aliasing (ce qui accélère d'autant les temps de rendu). Attention, je ne dénigre pas ton code, je ne fais qu'exposer les différences, j'espère que tu le comprends.

SmallPT/PurePT est aussi un raytraceur mais qui, en plus, prend en compte la lumière indirecte, par la technique dite du Monte Carlo path-tracing. Cette technique, utilisée de manière 'brute force' comme dans SmallPT/PurePT est extrêmement lente à cause de son principe même (on lance une infinité de rayons et la moyenne des résultats donne la solution exacte), mais par contre elle sert de 'référence' en terme de résultat car elle est capable de représenter tous les phénomènes lumineux (lumière indirecte, caustiques, glossy reflection/refraction, volumic scattering/sub-surface scattering, etc..) de manière correcte.

Le challenge, une fois que l'on a un path-tracer 'brute-force' qui marche, est d'implémenter petit à petit les techniques d'accélération pour réduire les temps de rendu ou - en pratique - obtenir moins de 'bruit' dans l'image pour un même temps de rendu.

J'ai déjà porté l'amélioration exposée sur le site de Kevin Beason: "L'Importance Sampling" des lumières, qui consiste à sampler les lumières directement au lieu de les chercher 'au hasard'. Cela marche, mais cela introduit un certain type d'artefacts lorsque l'on a des surfaces spéculaires (réfléchissantes) dans la scène, artefacts que l'on appelle "fireflies" (des petits points blancs dans l'image comme on peut le voir sur son site).

Il existe des méthodes pour contrer ces artefacts, notamment le papier dont je parle dans le thread de PurePT:
Density-based Outlier Rejection in Monte Carlo Rendering
que je suis en train d'essayer d'implémenter.

[Backup]

c'est pas mon code
je me suis contenté de le porté sur la version 5.11

je suis bien incapable de faire un raytracer (j'ai acces a la connaissance de base (St-magazine a fait un sujet la dessus assez complet )
mais ça ne m’intéresse pas plus que ça, en fait

meme si je m'en suis servi .. il y a longtemps avec POV sur Atari
puis ensuite Neon3D ....
j'aime bien tester les modelers...actuel (modeler+moteur de rendu)..
comme je suis tombé ,et converti ce code, je te le propose

[grabiller]

c'est pas mon code
je me suis contenté de le porté sur la version 5.11

je suis bien incapable de faire un raytracer (j'ai acces a la connaissance de base (St-magazine a fait un sujet la dessus assez complet )
mais ça ne m’intéresse pas plus que ça, en fait

meme si je m'en suis servi .. il y a longtemps avec POV sur Atari
puis ensuite Neon3D ....
j'aime bien tester les modelers...actuel (modeler+moteur de rendu)..
comme je suis tombé ,et converti ce code, je te le propose

Oui je comprends. Merci pour le code en tous cas, il y a toujours des choses intéressantes dans les techniques que chacun emploi.

[blendman]

Question bête, mais tu as pensé à regarder le code de cycle ?

Je sais que c'est du C/c++, mais comme tu as déjà adapté ce code en purebasic, peut-être que tu y trouverais des infos intéressantes .