struktura scény

[bolejt]

jak se do grafu scény zakomponuje fyzika či herní logika, tj. hmatatelný herní objekt definovaný zdravím (např.), nějakou logikou, vzhledem a fyzikálním objektem? když jsem prolézal net, tak jsem nalezl názory o vhodnosti grafu scény pouze pro renderování.

sám jsem už nějakou stromovou strukturu scény vymyslel, ale spíš si vyslechnu nějaké názory, abych věděl, jestli má tu cenu přetvořit ten můj bazmekt diagramu tříd na papíře do uml v pc

(klidně mě nasměrujte na nějakou vhodnou literaturu/stránku, ale většina scene graph literatury se imho zabývá jen renderováním)
_________________
Ball ball8;

[rezna]

grafiku a fyziku oddelit! - fyzikalni objekty jsou mnohonasobne jednodussi nez graficke

[Quiark]

Nebude to nějak tak, že herní objekt, který má herní vlastnosti (HP, počet nábojů, ...) a příslušnou logiku pak má odkaz na 3D objekt, který je jeho grafickou reprezentací a případně podobně i fyzikální objekt?
_________________
Mám strach

[am!go]

Objekty ve scene se casto nazyvaji entity.
Jeden z modernich zpusobu, jak osefovat tvuj problem, je tvorit nejaky komponenty (reprezentujici grafickou, fyzikalni, ... cast entity), ktery potom na entity napojujes.

edit: koukni na http://cowboyprogramming.com/2007/01/05/evolve-your-heirachy/

[bolejt]

rezna, Quiark: třeba v jMonkeyEngine physics je snaha vše integrovat do scene graph, jestli jsem to správně pochopil. viz. stránka s obrázky. můj návrh počítá s určitým oddělením, tohle jsem vytáhl z papíru do yUML:



pracuji ve 2d a Drawable je viditelná grafická reprezentace (Animovaný sprite například). PhysicalBody bych tvořil pomocí nějaké Factory.
no ale v každém případě jak byste pořádně oddělili fyziku ze scene graph, když grafická reprezentace je imho úzce spjatá s reprezentací fyzickou?

am!go: přečetl jsem článek i diskuzi, mrknul na zdrojové články a stáhl něčí zdroják.
jestli jsem to pochopil, Entity je v podstatě jakýkoliv objekt v herním světě. Component může být grafická reprezentace, fyzikální objekt, skript, dokonce i pohyb, cokoliv. Entity má seznam/pole svých Component. mno ještě se podívám na stáhnutý zdroják, nedokážu si představit, jak tohle funguje v praxi.

zkoušel jsi tento systém implementovat?
_________________
Ball ball8;

[Augi]

rezna a Quiark mají IMHO pravdu. Herní objekt by měl mít odkaz na svou grafickou a fyzikální reprezentaci a starat se o synchronizaci dat mezi nimi (např. fyzika vypočítá novou pozici, tak je potřeba ji zpropagovat do grafického objektu).

Jak si pastl ten grafík, tak ten výše uvedené splňuje. To, že máš herní objekty strukturované do stromu je Tvoje věc

[am!go]

[]semo[]

trochu rejpavej OT:
bolejt, od Javařů bych si inspiraci pro 3D grafiku zrovna nebral :)

Jinak já používal to, co už někteří zmiňovali: zvlášť fyzikální objekt, zvlášť grafický, zvukový, ...jakýkoliv další. Pak je v herním kódu třeba nějaký "GameObject", který to vše zapouzdřuje a teprve nad tím je Vehicle, Player, ... .
Ale i tak se herní kód může vyhnout použití "GameObjectu" a poskládat si z low level objektů nějaký speciální případ (např. 2x grafický objekt, jeden fyzikální, žádný zvuk).
_________________
Kdo jede na tygru, nesmí sesednout.
---
http://www.inventurakrajiny.cz/sipka/
Aquadelic GT, Mafia II, simulátory

[bolejt]

]semo[, Augi: uznávám, rozdělit vše na podsystémy je lepší, na entity a komponenty zdá se i skvělý.

am!go: díky, spousta materiálu pročtena. zítra nebo pozítří se na to vrhnu a dost možná sem přisypu další otravné otázky
_________________
Ball ball8;

[]semo[]

Ještě upřesním nějaké podrobnosti mnou používané architektury:

Pro transformace a hierarchii jsem měl objekt SceneNode, kterej obsahoval transformační matici a k ní příslušné metody, měl pod sebou další scene nody a celkově to byl strom.

[bolejt]

]semo[: jestli jsem to správně pochopil, tak tvé řešení je shodou okolností skoro to samé jako má Unity3d. abych upřesnil odlišnosti, které jsem postřehl: samozřejmě jiná terminologie (GameObject/Component) a transformační matici obsahuje jedna Component, která je v GameObject přítomna vždy.
každopádně bys mohl být dobrý zdroj informací...

předpokládám správně, že jsi zachoval "scene graph" pro grafiku?
jak tvoříš grafický, fyzikální SceneObject, to používáš něco na způsob Factory pattern?
jak přistupuješ k položkám SceneObject v tom seznamu? např. pokud z nějakého důvodu potřebuješ provést něco s fyzikálním SceneObject určitého SceneNode.
_________________
Ball ball8;

[]semo[]

[bolejt]

[]semo[]

[bolejt]

díky za informace. já se trochu obávám toho, že jakmile přidám mezi komponenty něco zajímavějšího, třeba ScriptComponent, postupně vyměním komplexní hierarchii za závislosti konkrétních Component. ale i tak to bude asi lepší...

ad zdrojáky: na téma Entity/Component je docela pomálu implementačních detailů a ty můžeš být někomu velkým přínosem, takže jestli jsou tvé zdrojáky z nekomerčního projektu a nevadí ti je zveřejnit...
_________________
Ball ball8;