[Java] grafica avanzata

[*andre*]

Ciao!
torno a chiedere il vostro aiuto. Mi sto dilettando a sviluppare applet con animazioni e qualche sorta di effetto grafico ma più vado avanti più sento la necessità di usare strumenti avanzati. Mi riferisco a accelerazioni Hardware per gestire gli effetti grafici e così via..
Leggendo su internet ho trovato alcuni esempi che utilizzano jogl come questo Particle Engine, qualcuno mi può chiarire le idee in merito?
intendo: a che cosa servono praticamente le librerie tipo jogl? quando è bene utilizzarle?
premetto che sono nuovo in questo campo, quindi qualcuno ha da suggerirmi un libro che tratta di questi argomenti da poter studiare? (anche in inglese ovviamente)
vorrei anche capire quali sono i metodi utilizzati dai programmatori esperti per sviluppare animazioni complesse senza gravare eccessivamente sulle prestazioni...

insomma mi piacerebbe esplorare questo ambito della programmazione e essendo un novizio chiedo a voi da dove iniziare

grazie e buone feste

EDIT: forse il titolo non è dei migliori

[wizard1993]

jogl sta per java binding for open gl
comunque il nome ti può far ben intuire, serve per grafiche avanzate a livello di giochi e di simulazioni 3d. se non erro con tali librerie sono stati creati Scilab e Nasa world wind

[*andre*]

Originariamente inviato da wizard1993

jogl sta per java binding for open gl
comunque il nome ti può far ben intuire, serve per grafiche avanzate a livello di giochi e di simulazioni 3d. se non erro con tali librerie sono stati creati Scilab e Nasa world wind

grazie
a me interessa il 2D però questo potrebbe interessarmi

qualche consiglio sui libri?

[PGI-Bis]

Se ti interessa il 2D puoi usare tranquillamente Java2D che è parte delle librerie standard (e usa l'accelerazione hardware dove disponibile).

Il problema è più che altro artistico nel senso che anche una volta che hai a disposizione le API, gli algoritmi e tutta la parte diciamo "meccanica", comunque devi affrontare la questione visiva.

Ad esempio sputare particelle è relativamente semplice. Il problema è che se l'aspetto di quelle particelle fa schifo farà schifo anche l'effetto nonostante l'eventuale raffinatezza del motore particellare.

[wizard1993]

se ti può interessare c'è una discussione dell'amico banryu su questi temi
http://www.hwupgrade.it/forum/showthread.php?t=1817420

[*andre*]

Originariamente inviato da wizard1993

se ti può interessare c'è una discussione dell'amico banryu su questi temi
http://www.hwupgrade.it/forum/showthread.php?t=1817420

lo avevo già letto :P mi è stato davvero utile

Originariamente inviato da PGI-Bis

Se ti interessa il 2D puoi usare tranquillamente Java2D che è parte delle librerie standard (e usa l'accelerazione hardware dove disponibile).

Il problema è più che altro artistico nel senso che anche una volta che hai a disposizione le API, gli algoritmi e tutta la parte diciamo "meccanica", comunque devi affrontare la questione visiva.

Ad esempio sputare particelle è relativamente semplice. Il problema è che se l'aspetto di quelle particelle fa schifo farà schifo anche l'effetto nonostante l'eventuale raffinatezza del motore particellare.

mmm ok si infatti quel programma li è "abbastanza" facile da realizzare se le particelle sono solo degli ovali(java.awt.geom.Ellipse2D) l'aspetto che vorrei approfondire è la creazione delle immagini delle particelle come fa in quel programma, tutte sfumate, con bicolore, etc fare tutto questo in tempo reale senza saturare la cpu. in merito avete qualche libro e/o quida che potrei consultare?
quindi dici che tutte le api di cui ho bisogno sono Java2D?

PS grazie e tutti e due :P

[PGI-Bis]

Lì le particelle che vedi sono dei quadrati ai quali è applicata come texture l'immagine di un grosso quadrato nero con al centro un pallino bianco sfumato. Questa texture è poi combinata con un colore. La combinazione applicata fa si che ciò che nell'immagine di base è nero diventi trasparente e ciò che è bianco opaco - con i livelli intermedi interpretati come opacità intermedie.

L'immagine usata per la texture è perciò la classica maschera alpha.

Ci sarà poi una certa funzione del colore, della posizione e della dimensione delle particelle nel tempo il cui effetto totale è quel movimento apparentemente caotico di luci colorate.

Se fai una ricerca per "particle engine" in rete trovi tutto l'armamentario. Puoi farlo sia con Java2D (in 2D) sia in Jogl (in questo caso in 3D sia in proiezione parallela che ortografica che è come il 2D in soldoni).

Il vantaggio di Jogl (cioè dell'uso diretto di funzioni OpenGL) sta in ciò che tra le funzioni offerte ce ne sono di specifiche per realizzare direttamente questo genere di combinazioni colore-maschera.

[*andre*]

Originariamente inviato da PGI-Bis

Lì le particelle che vedi sono dei quadrati ai quali è applicata come texture l'immagine di un grosso quadrato nero con al centro un pallino bianco sfumato. Questa texture è poi combinata con un colore. La combinazione applicata fa si che ciò che nell'immagine di base è nero diventi trasparente e ciò che è bianco opaco - con i livelli intermedi interpretati come opacità intermedie.

L'immagine usata per la texture è perciò la classica maschera alpha.

Ci sarà poi una certa funzione del colore, della posizione e della dimensione delle particelle nel tempo il cui effetto totale è quel movimento apparentemente caotico di luci colorate.

Se fai una ricerca per "particle engine" in rete trovi tutto l'armamentario. Puoi farlo sia con Java2D (in 2D) sia in Jogl (in questo caso in 3D sia in proiezione parallela che ortografica che è come il 2D in soldoni).

Il vantaggio di Jogl (cioè dell'uso diretto di funzioni OpenGL) sta in ciò che tra le funzioni offerte ce ne sono di specifiche per realizzare direttamente questo genere di combinazioni colore-maschera.

ecco e qui è dove casca l'ignorante come me...
io pensavo di fare chissà cosa la funzione di aggiustare il colore la posso fare anche io analizzando ogni pixel e prendendone il valore alpha e cambiare solo il colore con quello desiderato, però mi puzza di pesante

per le ombre del testo invece? (hei ora sono curioso )

comunque mi devo trovare un buon libro che tratta questi argomenti...

[PGI-Bis]

Il principio della colorazione di una maschera alfa è quello lì dei pixel. L'operazione concreta dipende dalle librerie. Ad esempio in Java2D usi una composizione DST_IN. Tutta roba terra terra, intendiamoci. In pratica pigli e ti crei un'immagine della particella trasparente, tipo questa:



e la carichi in una BufferedImage.

Questa è la maschera (chiamiamola mask). Poi crei una BufferedImage vuota, delle stesse dimensioni della particella che sarà il tuo buffer (chiamiamola appunto buffer).

Poi entrano in gioco le regole di combinazione di porter-duff. Si tratta di funzioni precotte che stabiliscono come il colore del punto in cui si disegna può combinarsi con il colore di ciò che gli viene disegnato sopra.

Una di queste regole, "destination in", che in Java2D è rappresentata AlphaComposite.DstIn, dice che il colore della superficie non cambia ma quel colore assume come trasparenza la trasparenza del "pennello".

Significa che se io disegno un quadrato arancione, imposto la regola DstIn e poi disegno su quel quadrato la mia immagine, il risultato sarà i pixel del quadrato resteranno arancioni MA il loro valore di trasparenza cambierà secondo la trasparenza dei corrispondenti pixel dell'immagine.

Dunque dato il buffer, lo riempio del colore che voglio io:

Graphics2D g = buffer.createGraphics();
g.setColor(Color.YELLOW);
g.fillRect(0, 0, buffer.getWidth(), buffer.getHeight());

imposto la composizione DstIn:

g.setComposite(AlphaComposite.DstIn);

e disegno la maschera della particella:

g.drawImage(mask, 0, 0, null);

Il risultato è che "buffer" diventa la mia particella colorata.

E' come colorare pixel per pixel solo che, se l'hardware lo permette, ogni drawImage è realizzato con un'unica invocazione sulla pipeline di rendering.

Posizione e dimensioni sono controllabili con le trasformazioni affini. Dato il buffer "colorato" e il Graphics2D della superficie su cui voglio disegnare la particella (che puoi essere un Canvas o un JComponent o un BufferStrategy eccetera), controllo la posizione con la traslazione e la dimensione con il fattore di scala. Con un secondo AlphaComposite controlli la trasparenza generale della particella.

In breve un metodo Java2D che disegna una particella colorata, partendo da una maschera png "MASK", può essere questo:

    private final AffineTransform TRANSFORM = new AffineTransform();
    private void drawParticle(Graphics2D graphics, int cx, int cy, double scale, float transparency, Color color) {
        AffineTransform t = graphics.getTransform();
        Graphics2D g = BUFFER.createGraphics();        
        g.setPaint(color);
        g.fillRect(0, 0, BUFFER.getWidth(), BUFFER.getHeight());
        g.setComposite(AlphaComposite.DstIn);
        g.drawImage(MASK, 0, 0, null);
        TRANSFORM.setToTranslation(cx, cy);
        TRANSFORM.scale(scale, scale);
        graphics.transform(TRANSFORM);
        Composite c = graphics.getComposite();
        graphics.setComposite(AlphaComposite.getInstance(AlphaComposite.SRC_OVER, transparency));
        graphics.drawImage(BUFFER, -BUFFER.getWidth() / 2, -BUFFER.getHeight() / 2, null);
        graphics.setComposite(c);
        graphics.setTransform(t);
    }

Questo per quanto riguarda l'aspetto "istantaneo". Poi c'è la questione del "ciclo vitale" delle particelle: appare in una certa posizione, con una certa dimensione, un certo colore, viaggia con una certa velocità in una direzione, cambiando nel frattempo colore, dimensioni e trasparenza. Insomma, c'è di che divertirsi.

Per quanto riguarda l'ombra del testo, so dell'esistenza di svariate tecniche in 3D ma non ne saprei realizzare neppura una. Ci sono comunque diversi motori di rendering 3D in java (JME, Ardor3d o Xith per citarne tre tra i tanti) che hanno le lore funzioni di generazione delle ombre già bell'e e pronte da usare.

In 2D è un "far finta che", realizzato con due livelli di disegno. Prima disegni il testo o la figura geometrica nera, poi disegni il testo o la figura nel suo colore reale, leggermente spostata rispetto al disegno precedente per dare l'illusione di profondita.

Per più oggetti, disegni prima tutte le "ombre" e poi tutti gli oggetti. Il risultato di quella che un semplice disegnare le cose una sopra l'altra è l'illusione ottica di un'ombra.

[*andre*]

Sono veramente senza parole, primo per le cose che sai e secondo per la semplicità di java che non credevo arrivasse fino a questo punto!

Grazie mille per l'interessamento e ora so su cosa focalizzarmi, mi prenderò un bel libro che tratta java2D e me lo studio per bene..

esistono metodi preconfezionati per effetti "tipo" blur di sfocamento che non usino ConvolveOp? (risulta troppo pesante se applicato a alti livelli)

PS: curiosità esiste un metodo per capire da applet se sul PC Client è installato java?

[PGI-Bis]

Non ci sono alternative predefinite a ConvolveOp.

Per verificare la presenza di un JRE puoi fare riferimento a questa pagina della documentazione Se

http://java.sun.com/javase/6/docs/te...ml#deplToolkit

in pratica si tratta di includere un file javascript tramite il quale è possibile automatizzare l'installazione di un JRE nel caso in cui non sia presente.

[*andre*]

Originariamente inviato da PGI-Bis

Non ci sono alternative predefinite a ConvolveOp.

Per verificare la presenza di un JRE puoi fare riferimento a questa pagina della documentazione Se

http://java.sun.com/javase/6/docs/te...ml#deplToolkit

in pratica si tratta di includere un file javascript tramite il quale è possibile automatizzare l'installazione di un JRE nel caso in cui non sia presente.

peccato non ci sia qualcosa di predefinito, ma ho trovato ugualmente un metodo per fare le ombre a degli shape, utilizzo delle trasformazioni affini e canale alpha

grazie per la dritta sulle applet, quando l'avrò finita vedrò di implementare quel controllo li.

ma ora mi è venuto un dubbio.. sempre in termini di prestazioni, esite la classe VolatileImage che è una immagine salvata nella memoria della scheda video, so che essa può perdere il proprio contenuto in seguito ad azioni che non si possono controllare direttamente ma in teoria non dovrebbe essere moolto più veloce compiere calcoli su immagini volati che su normali? mi è venuto in mente ciò perchè in seguito a un'animazione devo fare scomparire pian piano degli oggetti a schermo.. e mi sono chiesto se al posto di ridisegnare ogni oggetto e applicargli un AlphaComposite diverso non sarebbe stato meglio disegnare tutto dentro una immagine volatile e poi disegnare essa nel mio contesto grafico con un alphaComposite solo, che te ne pare dle mio ragionamento contorto?

[PGI-Bis]

Non vedo un vantaggio nell'operazione che proponi. In questo senso. Disegnano "oggetto per oggetto" esegui questa serie di operazioni:

g.setComposite(trasparenza);
...disegna N oggetti su g

Usando un buffer avremmo:

disegna N oggetti sul buffer
g.setComposite(trasparenza);
g.drawImage(buffer...);

Il fatto è che se puoi disegnare tutto su un'immagine e poi applicare quell'immagine con un unico alphacomposite allora puoi anche organizzare il disegno direttamente su "g" applicando un solo alphacomposite. In altri termini, se devo disegnare 3 oggetti trasparenti, non è necessario dire:

g.setComposite(trasparenza);
g.drawQualcosa
g.setComposite(transparenza);
g.drawQualcosa
g.setComposite(transparenza);
g.drawQualcosa

ma è sufficiente:

g.setComposite(trasparenza);
g.drawQualcosa
g.drawQualcosa
g.drawQualcosa

Questo perchè la regola di composizione (come le trasformazioni) è applicata ad ogni operazione successiva alla sua entrata in vigore.

[*andre*]

si si io volevo utilizzare un alphacomposite solo, scrivevo tutto dentro un "buffer" e poi scrivevo quel buffer dentro il mio Graphics a cui impostavo un alpha composite solo

mmm però per avere una struttura di questo tipo dovrei cambiare buona parte del codice..

ma ora una domanda, se ho una struttura di questo tipo:

JFrame
 JPanel1
 JPanel2
  JPanel2.1
  JPanel2.2
 JPanel3

quando io chiamo il repaint del JFrame lui a sua volta scorre tutti i suoi figli e chiama per chiascuno il paint passandogli un graphics che rappresenta la porzione di spazio da loro occupata?
perchè se così fosse io mi farei una struttura personalizzata di questo tipo adattandola alle mie esigenze (cioè potendo applicare trasformazioni affini etc utilizzando un solo drawImage, poi anche fosse peggiore ho imparato smepre qualcosa )

[PGI-Bis]

Il graphics è uno solo per finestra e tutti i panelli e pannellini contenuti nella finestra ricevono quell'unico graphics.

In pratica io componente genitore disegno me stesso, poi vado a guardare in che punto si trova il figlio, sposto l'origine degli assi del graphics con un'affinetransform, imposto un clip che limita il graphics alla superficie occupata dal figlio e poi gli passo il mio graphics.

Il risultato è che per ogni componente il punto (0,0) corrisponde al suo angolo in alto a sinistra (anche se il componente può trovarsi al centro della finestra).

Insomma, stesso graphics ma sistemi di coordinate diversi.

Occhio che la condivisione del graphics fa sì che eventuali trasformazioni applicate nel padre si riflettano sui figli.

[Tommo]

Java != Grafica Avanzata.

Cambia linguaggio, ti fai un favore
Mai vista una gestione della grafica così lenta e penosa, con lo stesso sforzo impari a fare le stesse cose con la DirectX.

[PGI-Bis]

Evvai, iniziamo il 2010 con una bella stronzata.

[*andre*]

Originariamente inviato da Tommo

Java != Grafica Avanzata.

Cambia linguaggio, ti fai un favore
Mai vista una gestione della grafica così lenta e penosa, con lo stesso sforzo impari a fare le stesse cose con la DirectX.

beh sicuramente non è leggerissima ma (io parlo per me e con la mia esperienza eh) per avere una grafica veloce e bella bisogna studiare e sudare e sudare in java come in qualsiasi altro linguaggio credo, chi più chi meno. Proprio perchè ogni linguaggio ha un approcio differente. Poi se tu parli di librerie la storia cambia, se credi che Java2D non sia sufficientemente performante esponi perchè e un rimedio io sono sempre aperto a miglioramenti

PS: comunque personalmente il C++ non mi piace proprio, e poi ti voglio vedere a fare le applet in C++ (a me queste cose servono per quel motivo)

Originariamente inviato da PGI-Bis

Il graphics è uno solo per finestra e tutti i panelli e pannellini contenuti nella finestra ricevono quell'unico graphics.

In pratica io componente genitore disegno me stesso, poi vado a guardare in che punto si trova il figlio, sposto l'origine degli assi del graphics con un'affinetransform, imposto un clip che limita il graphics alla superficie occupata dal figlio e poi gli passo il mio graphics.

Il risultato è che per ogni componente il punto (0,0) corrisponde al suo angolo in alto a sinistra (anche se il componente può trovarsi al centro della finestra).

Insomma, stesso graphics ma sistemi di coordinate diversi.

Occhio che la condivisione del graphics fa sì che eventuali trasformazioni applicate nel padre si riflettano sui figli.

ok come sospettavo vedo di studiare qualcosa..
Ma mi puoi dare un parere?
Che te ne pare di fare un contest educativo?
Cioè mi spiego meglio: di solito nei contest si cerca il miglior algoritmo per risolvere un certo problema etc etc, invece perchè noi non proviamo a proporre una nostra implementazione di applet così che Voi (intendo programmatori seri) possiate insegnare a Noi (intendo novizi o quasi) come migliorare il codice
il primo potrebbe essere una applet quadrata a sfondo nero che al centro abbia una fonte di particelle (eh si mi piacciono ) e che si spostino verso l'esterno a mò di spirale, non porta via molto tempo e può insegnare molto (così da entrare nello specifico della grafica)

[PGI-Bis]

In tutta onestà al momento sono un po' preso dal tentativo di far muovere le zampe a questo grandissimo figlio di una mesh (e, si sa, la mesh è un po' zoccola)



La fiera resistenza che sta opponendo è direi quasi ammirevole.

Che è poi la metafora della programmazione di applicazioni grafiche: non è mai un problema di programmazione in sè. Semplicemente a un certo punto devi iniziare a caricare dei contenuti nel tuo programma e allora scopri che non ci sono - o se ci sono non sono gratuiti. E allora devi farti pure quelli. Solo che un conto è programmare, un conto è disegnare.

[Tommo]

Originariamente inviato da PGI-Bis

Evvai, iniziamo il 2010 con una bella stronzata.

Ovvio che trollavo, ma rimane che Java non si sia mai visto usare per la grafica 3D, per quanto oggi un motore grafico può essere leggerissimo per la CPU.
Non credo affatto che si possano trascurare tutti i problemi che java ha nell'ambito delle applicazioni realtime...