[friskon]

OGRE (Object-Oriented Graphics Rendering Engine) è un motore di rendering 3D, flessibile, orientato alla scena .

Come dice il suo nome, OGRE è "solo" un motore di rendering. Come tale, il suo scopo principale è quello di fornire soluzioni generali per il rendering grafico. Nonostante questo ci sono alcune strutture come vettori e matrici, gestione della memoria che hanno solo lo scopo di aiuto. Chi cerca una soluzione tutto in uno per sviluppare un videogioco o una simulazione deve fare attenzione, poiché per esempio non fornisce supporto per l'audio e per la fisica.

OGRE ha una struttura orientata agli oggetti con un'architettura a plugin che consente l'aggiunta di caratteristiche. OGRE è un motore basato su scene, con il supporto di vari Scene Managers, come Octree, BSP.

OGRE è completamente multipiattaforma, con il supporto delle DirectX e OpenGL. Al momento esistono dei binari precompilati per Linux, Mac OS X, e tutte le maggiori versioni di Windows.

OGRE supporta anche shaders personalizzati sia con vertex che con fragment program, scritti in GLSL, HLSL, Cg e asm.

Il landscape scene manager (per gli ambienti esterni) ha il supporto per il LOD progressivo (Progressive LOD), che puo' essere creato automaticamente o manualmente.

Il motore di animazione ha il pieno supporto per l'Hardware Weighted Multiple Bone Skinning, che puo' essere impostato attraverso delle pose per il Full Pose Mixing.
Fonte : Wikipedia it

Screen di qualche gioco :






Pagina di Download : Ogre Download

[GEARS_CORPORATION]

Wow beloooooo!!!
lo avete provato???

[friskon]

no, non penso sia facile da utilizzare... ma i risultati sono strabilianti

[GEARS_CORPORATION]

è si...si vede dal screen...è Super...

[Riddick]

Si deve saper usare il C++ moooolto bene, e un programma di modellazione 3D <.<.

[GEARS_CORPORATION]

nuuuuuuuuuoooooooooooooooooo...il c+++

[Riddick]

E' si, perchè il C++ supporta le librerie DirectX e OpenGL ed è potente come linguagio sennò il migliore, però per scrivere un gioco con un grafica del genere col C++ ci vogliono anni mesà, e tante e tante e tante e tante righe di codice XD, per scrivere solo "Ciao Mondo" si deve creare sto panico qua XD:


#include <iostream> //Libreira standar del C++
using namespace std;

int main()
{
cout << "Hello World !"<<endl; //cout serve per stamapare Hello World sullo schermo
system("pause"); //Non si chiude il promt finchè non si preme Invio
return 0;
}

[GEARS_CORPORATION]

x me è ultra difficile vb net, altro ke c++

[Riddick]

Visual basic.net, non è un linguaggio paragonabile al C++ <.<, il vb.net è solo per chi piace "cazzeggiare" XD.

[friskon]

niente paura, ci sono moltissimi tool sviluppati per questo engine...

[Riddick]

friskon io mi fido di te, quindi ora lo scarico e vedo un po' se trovo qualcosa.

[GEARS_CORPORATION]

facci sapere comè xk sembra molto bello...

[friskon]

Irrlicht engine è fatto con i tools incorporati, è più semplice di questo... molto molto più semplice...

poi dai un 'occhio anche qui per qualche tool :
http://www.ogre3d.org/wiki/index.php/Ass...n_pipeline
http://www.ogre3d.org/download/tools (come vedo blender è dappertutto)

Demo dell' Engine :
[youtube]http://www.youtube.com/watch?v=woHZRUlOQqo[/youtube]

[GEARS_CORPORATION]

il water simulation è stra figooo...

[steve]

ma gestisce anche un pò di fisica o per physics integration intendono che si può aggiungere un motore fisico a parte? (minuto 2:00)

[friskon]

penso di si, controlla sul forum ufficiale, perchè aggiungere magari la fisica di nvidia non sarebbe una cattiva idea.

[steve]

ah ecco:
ReferenceAppLayer provides an example of how to combine OGRE with other libraries, for example ODE for collision & physics

non ha un engine fisico, ne può integrare un altro (physX, newton, havok, ode, bullet, novodex, ecc...)

[friskon]

e quando fa vedere la fisica nella techdemo ? O.o

[steve]

presumo sia stato fatto per far vedere che può integrare un motore fisico separato, difficile capire quale.
da quanto ho capito non ha un motore fisico suo ogre...

[steve]

vi consiglio di dare un occhiata alla demo, è veramente impressionante.
si può scaricare da qui, il primo file è la demo per windows, il secondo è la demo per linux e il terzo è un avventura grafica (fatta con una versione vecchia di ogre)

[G.Freeman]

Ho provato il programma ultimamente ed è stupendo. Mi chiedevo come sarebbe se si usasse euphoria come engine fisico...

[Riddick]

Bullet è il migliore , comunque se ora stai iniziando a creare giochi in c++, te lo sconsiglio vivamente ogre3d, non è per nulla facile si devono configurare un bel po' di cose, e la documentazione scarseggia (Almeno per quello che ho visto io). Domanda a steve che si sta esaurendo per configurare le gui, motore fisico e openal (per l'audio) XD.

[G.Freeman]

Ho provato il programma per semplice curiosità... sono dell'idea che da solo con un programma del genere non vado da nessuna parte. Comunque è vero, Bullet è davvero stupendo XD.

[friskon]

difatti è solo un engine, si deve aggiungere il resto per fare il lavoro completo.

[steve]

comunque per precisare, bullet è un motore fisico mentre euphoria serve per simulare i movimenti (principalmente degli esserei umani).

[G.Freeman]

Si si vero infatti viene sempre (o quasi) abbianto ad altri engine come ad esempio havok

[steve]

Rilasciato Ogre3D 1.7.2 [Cthugha]
link, è uscito da poco e devono ancora aggiornare la pagina (per adesso credo sia disponibile solo in SVN, ma a breve ci sarà pure il download precompilato)

[Riddick]

Eh, circa due o 3 giorni fa, ma ho letto che non c'era il download, grazie di aver aggiornato la discussione.

[steve]

Rilasciato Ogre 1.7.3

Altri sei mesi sono passati, ed è tempo per un'altra versione di manutenzione per il ramo stabile 1.7 (nome in codice 'Cthugha'). Come al solito non ci sono modifiche di funzionalità o danni alle API in questa versione - quelli ci sono nel ramo di sviluppo instabile - che ovviamente si può prendere da Mercurial se volete unirvi a noi per superare le soglie.

Per adesso solo i sorgenti d'origine sono pronti per il download per la 1.7.3, le versioni SDK saranno disponibili a breve.

Cambiamenti dalla versione 1.7.2:
[spoiler]
iOS: Remove the animation timer. Since DisplayLink is used by default now, this only hurts performance of things like input.
Some small changes to ensure that the terrain and paging libs are added to linker flags for SDK sample builds.
Consider weight when scaling in AnimationTracks
Only allow to set custom render capabilities before RenderSystem is fully created
iOS: Fix to prevent absolute paths from being inserted into resources.cfg for iOS to fix running the sample browser on devices.
OS X: The Cocoa view has no use inside the main library. Moving into the GL Rendersystem where it is actually used.
OS X: Disabling CoreGraphics error checking by default
OS X: 64 bit Cocoa support. New dependencies are also available to download. Fixed a few uninitialized variables along the way. Also updated GLEW to the same version as in default, the older version had some Apple specific bugs that needed to be resolved.
Several fixes for the Xcode templates such as: file permissions for the installer, iOS device orientation.
Adding Cocoa window event handling. Plus several other fixes for parameter parsing and other things. Thanks to jdiogo for finding the bugs.
OS X: Build fix when targeting 10.5 or earlier.
OS X: A few fixes for Cocoa windowing. Now plays nicer with externally created windows.
Clean up several warnings(hidden local variables, unused functions)
iOS: Fix orientation change support. Use UISupportedInterfaceOrientations in your apps info property list to restrict which orientations are supported by your application.
Fix a couple comment typos
GLES: Disable ENABLE_GL_CHECK, again.
GLES: Fix for images with custom mipmaps. The dimensions were never being reduced for each mipmap level. As a side effect, memory usage is also reduced.
iOS: IOKit isn’t needed at all and causes link errors with iOS 4.2.
Separate out all the OS X and iOS specific code from SampleBrowser.cpp. It was getting a bit unruly and difficult to maintain
iOS: Improve orientation support. Separate EAGLView into its own files.
iOS: Several fixes to the Xcode templates regarding viewport orientation and some cleanup for readability.
Patch 3116577: Plane equality operators. Also cleaned up some documentation.
Fix a catch-22 that prevented OGRE_BUILD_PLATFORM_IPHONE from showing up in CMake-Gui.
Fixed an incorrect error message in the Terrain component.
Do not offer the Carbon API option in 64-bit Mac builds and default to Cocoa
Allow the retrieval of NSOpenGLContext and NSOpenGLPixelFormat easily in OSXCocoaWindow
Specify the NSOpenGLFPAScreenMask to resolve ambiguity in the pixel format on multiple display systems
In OSXCocoaWindow::createWindowFromExternal, don’t force the window to be made key and ordered in front. As an external window, the calling application should have full control over window behaviour.
When creating an external window in Cocoa, don’t centre the window (app should be in charge of that)
Also don’t mess with the first responder.
Fix using multiple Cocoa windows with Ogre.
Previously the window delegate was incorrectly listening in on the events of *every* window, not just the one containing Ogre. This meant if the application had more than one window (Ogre or otherwise), the Ogre windows would get confused with all the events from different windows.
Fix this by making sure each delegate only attaches to the NSNotifications of the specific window it’s concerned with.
Support getCustomAttribute() on Texture, only GL extracts anything interesting so far but more can be added
This is pretty much essential if you want to get to internal API data for resource sharing without down-casting, which itself requires otherwise unnecessary linking to plugins. It’s why we’ve offered this for RenderWindow etc in the past, I’m not sure why it’s never been done for Texture.
Also support retrieving the FBO ids directly from render targets on GL (already allowed retrieval of FBO struct but again that requires linking)
Added support for spotlight_viewproj_matrix_array GPU parameter
Changed DataStream::getAsString and MemoryDataStream constructors to deal with streams of unknown size
[Papercut] Add destroyRenderTarget function to Ogre::Root
Fix a problem with using some of the lower-level renderable callbacks such as RenderObjectListener to alter shader parameter state – mGpuParamsDirty would not be updated to reflect this and as such things like manual param variances within light iteration loops would not be propagated.
Allow user to mark GPU params dirty themselves to resolve this.
iOS: Rework some of the sample browser code to shut down properly on iOS
GLES: Use the correct GL type for BGRA textures
OS X: Use correct pixel format attribute name for specifying FSAA in Carbon windows.
GL: Only bind up to the max supported number of render targets since not all implementations support 8. This prevents a few OpenGL errors.
iOS: Clean up the FSAA/framebuffer code in swapBuffers. This should resolve issues on iOS 4.1 that have been reported. Bug #384
iOS: Don’t search for X11 if building for iOS. I’m surprised that this hasn’t been found until now. Apparently most devs have the X11 package installed.
iOS: 2 fixes. The compiler should be g++ instead of gcc and switching the architecture to build for both armv6 and armv7.
OS X: A few CMake fixes to ease building for universal libraries. Upping the minimum OS to 10.5(it’s required for x86_64). Also updating the list of Boost versions to be current.
Don’t apply visibility settings to statically built samples. Fixes linking problems with Xcode 4 and iOS. (Backporting to 1.7)
Remove a GL ES 2 reference in the 1.7 branch
iOS: The meaning of ARCHS_UNIVERSAL_IPHONE_OS changed in Xcode at some point to just armv7. Changing it to Standard will compile for both armv6 and armv7.
OS X: A few small tweaks for Cocoa windows. Clearing the framebuffer right away, fixing multisampling for example
iOS: Let’s pretend that the iOS simulator doesn’t have SSE. (Works around a Xcode 4 bug)
OS X: Add support for 8 FSAA samples
Update the boost versions to look for.
Patch 3153910 – Fix a typo in MovableObject:etRenderQueueGroupAndPriority. Render queue priority should be set to the priority argument, not the queue ID.
Patch 3221772 – iOS: Fixed bug in setting up the viewport if the lower-left corner is not 0,0.
RTSS: Fix the “Disco” effect in the Shader Sample on OS X. Thanks to Wolfmanfx!
Fix a documentation spelling error in 2 places
Patch 3046729 – Improvements on previous ProgressiveMesh patch. “Sometimes it seems to be actually desired to list itself as neighbor, so instead of denying this, we rather make the loop in ProgressiveMesh:MTriangle::notifyRemoved more robust to these edge conditions.”
GLES: Fix using PVR textures
OS X: Fix a crash when switching between windowed and full screen when using the Cocoa interface.
Bug #397: Fix the build with some versions of GCC.
[Papercut] Image getColourAt parameters should be type size_t, not int
373 – [Papercut] Image has getColourAt but not setColourAt
Bug 409 – System freezes in GLPixelUtil::getMaxMipmaps when width or height is 0. Bug was reported for GL but could affect GL ES as well.
Reformat a little text in an exception so that it follows the format used elsewhere.
Bug 374 – [Papercut] PixelBox should have getColourAt and setColourAt
Bug 365 – [Papercut] void BillBoardSet:etMaterial (const MaterialPtr &material) is missing
Bug 340 – Viewport::clear() saves and re-sets the previous Viewport, even if that Viewport has since been deleted
Bug 344 – Add utility functions to enable/disable skybox/dome/planes instead of destroying and recreating.
Bug 423 – Fix for looking up for texture definitions in very complex compositor setups in getSourceForTex and getTargetForTex
iOS: Explicitly specify the release lib paths so that libraries are always installed to the correct places. This fixes the problem of duplicate, single architecture libraries in SDK builds.
iOS: Remove -fno-regmove flag to keep Clang from complaining about it.
Update the SDK CMakeList template
Several updates and fixes for the OS X and iOS SDK build scripts
OS X: Fix a long standing issue that often prevented 3 situations: Building with Clang, 64 bit debug builds and linking with Xcode 4.
OS X: Add macAPI option to the config dialog
Added Gentoo install location for Cg to the FindCg.cmake script
Fixed a comment in OgrePixelFormat.h
Modified FindTBB.cmake to cope with TBB 3 paths
Fixed a build error with GCC 4.6
Xcode 4 templates and installer files
iOS: Normalize the case of the word Media in scripts. Simplifies a little scripting.
[/spoiler]

[steve]

Rilasciata la prima release candidate di Ogre 1.8 (link), presumibilmente nell'arco di un mese verrà rilasciato definitivamente e poco dopo metteranno anche l'SDK precompilato.
Attualmente non è ancora disponibile una lista completa delle novità, ma sostanzialmente dovrebbe essere simile a questa: ByatisNotes.
Hanno anche pubblicato una serie di statistiche interessanti.

PS. Nel frattempo il mio giochino con ogre è completamente giocabile e pronto per un upgrade a ogre 1.8 release