Autor Wątek: Architektura: Wpływ rodzaju obiektu na kolejność i sposób renderowania  (Przeczytany 2970 razy)

Offline shadow864

  • Użytkownik

# Lipiec 23, 2014, 20:05:16
Hejka

Chciałbym się dowiedzieć jak w swoich aplikacjach radzicie sobie zależnością miedzy rodzajem obiektu a renderowaniem. Chodzi mi o to że np chce stworzyć sobie obiekt który będzie lustrem (plane reflection + stencil).

Wymaga to renderowania najpierw sceny bez lustra, później lustra do stencilu później odbicia obiektów na scenie itd...

Mogę teoretycznie rozwiązać to na zasadzie że obiekt lustra zawiera wskaźniki na obiekty które ma odbić i to by pozwoliło na ukrycie dla renderera informacji że jest to lutro. Ono z kolei by  rysowało to co chce i do czego a także ustawiało techniki dla obiektów do renderowania, a na podstawie technik byłby ustawiane Stencil, Blend itd

Renderer.cpp

void Renderer::Draw()
{
...
std::for_each(m_ModelObjects.begin(), m_ModelObjects.end(),
[&](IRenderable* object)
{
object->Render(m_GraphicsDevice);
}
);

m_SwapChainPtr->Present(0, 0);
...
}


MirrorObject.cpp
void MirrorObject::Render(GraphicsDevice* device, ETechnique::TYPE technique)
{
__super::Render(device, ETechnique::StencilOnly);


std::for_each(m_Objects.begin(), m_Objects.end(),
[&](IRenderable* object)
{
object->SetReflection(R);
object->Render(device, ETechnique::Normal);
object->SetReflection(DirectX::XMMatrixIdentity());
}
);

__super::Render(device, ETechnique::Normal);

Co o tym myślicie?
« Ostatnia zmiana: Lipiec 23, 2014, 21:23:01 wysłana przez shadow864 »

Offline Mr. Spam

  • Miłośnik przetworów mięsnych

Offline Krzysiek K.

  • Moderator
    • DevKK.net

# Lipiec 23, 2014, 23:12:22
Cytuj
to by pozwoliło na ukrycie dla renderera informacji że jest to lutro
Co jest katastrofalnym w skutkach założeniem.

Cytuj
std::for_each(m_ModelObjects.begin(), m_ModelObjects.end(),
                [&](IRenderable* object)
                {
                        object->Render(m_GraphicsDevice);
                }
Podobnie jak zresztą to też jest katastrofą. Próbowałem raz napisać silnik w ten sposób - problemy pojawiają się wręcz lawinowo.

Cytuj
Co o tym myślicie?
Próbujesz ukryć przed rendererem proces renderowania. To co w takim razie miałby on robić?
Efekt można przewidzieć: logika renderowania rozlezie Ci się po wszystkich obiektach, w efekcie czego kawałkiem renderera będzie każdy obiekt, kompletnie nie będzie w tym przejrzystości, przy każdym kroku pojawią się dodatkowe zależności, a jak będziesz chciał coś zoptymalizować to się okaże, że przy tej architekturze po prostu nie idzie. Zresztą pierwsze problemy z takim podejściem widzisz już w przypadku właśnie luster.


Jak bym za to radził zrobić? Tak, żeby renderer był rzeczywiście odpowiedzialny za rendering. Czyli pełny dostęp renderera do wszystkich rzeczy graficznych tak, żeby mógł rozwiązywać tego typu problemy (co się w czym odbija, co rzuca na co cień, co widzi kamera, które światło oświetla który obiekt, itp).

Offline shadow864

  • Użytkownik

# Lipiec 24, 2014, 20:49:38
Dzięki wielkie za odpowiedz. Czy mógłbyś mi w takim razie doradzić gdzie znaleźć jakieś dobre materiały na ten temat?

Chętnie też dowiem się jak inni tworzą swoje renderery :)

Offline Paweł

  • Użytkownik

  • +3
# Lipiec 24, 2014, 21:09:05
Ale nad stylem to popracuj. To co wkleiłeś to c++03 z lambdami.
1. Zamiast std::for_each(m_Objects.begin(), m_Objects.end(),
                [&](IRenderable* object)
       {
pisz: for(auto* object : m_Objects){
2. void MirrorObject::Render(GraphicsDevice* device, ETechnique::TYPE technique)
{
        __super::Render(device, ETechnique::StencilOnly);
zgaduję że Etechnique to namespace a TYPE to enum. Zamiast tego zrób enum class ETechnique.

3. "__super" , czy to jakieś niestandardowe rozszerzenie kompilatora? Jeśli nie to nie powinno zaczynać się od "__".

Sorry za offtopic.

Offline Xirdus

  • Redaktor

# Lipiec 24, 2014, 22:16:00
3. "__super" , czy to jakieś niestandardowe rozszerzenie kompilatora?
Tak (MSVC). Działa jak super z Javy. Osobiście strasznie mi się nie podoba takie oddelegowywanie funkcjonalności do klasy bazowej.
« Ostatnia zmiana: Lipiec 24, 2014, 22:17:39 wysłana przez Xirdus »

Offline Krzysiek K.

  • Moderator
    • DevKK.net

# Lipiec 24, 2014, 23:06:16
Cytuj
Ale nad stylem to popracuj. To co wkleiłeś to c++03 z lambdami.
Jeżeli dobrze kojarzę, nadal jest to poprawny C++11, więc nie przesadzaj.

Offline shadow864

  • Użytkownik

# Lipiec 24, 2014, 23:17:48
Jeżeli dobrze kojarzę, nadal jest to poprawny C++11, więc nie przesadzaj.


I nie każdy kompilator pozwala na :

for(auto* object : m_Objects){
http://msdn.microsoft.com/en-us/library/vstudio/hh567368%28v=vs.110%29.aspx

Ale dzięki wielkie za uwagi :)
« Ostatnia zmiana: Lipiec 24, 2014, 23:19:34 wysłana przez shadow864 »

Offline Xirdus

  • Redaktor

# Lipiec 24, 2014, 23:32:03
I nie każdy kompilator pozwala na :

for(auto* object : m_Objects){
http://msdn.microsoft.com/en-us/library/vstudio/hh567368%28v=vs.110%29.aspx
Nie powinny cię interesować stare kompilatory. BTW, ta gwiazdka jest zbędna.

Offline Krzysiek K.

  • Moderator
    • DevKK.net

# Lipiec 25, 2014, 00:10:50
Cytuj
Nie powinny cię interesować stare kompilatory.
To akurat zależy od bardzo wielu czynników. W szczególności w dużych firmach przejście na nowy kompilator to niemała zmiana.

Cytuj
BTW, ta gwiazdka jest zbędna.
Swoją drogą, pisanie "auto" obok "m_Objects" jak dla mnie trochę zalatuje hipokryzją - z jednej strony widać to wpływy notacji węgierskiej dla celów czytelności, a z drugiej "auto" radykalnie tą czytelność zmniejsza.

Offline Xirdus

  • Redaktor

  • +1
# Lipiec 25, 2014, 00:14:36
@up
auto oznacza dedukcję typu, m_ składową klasy. Żadnej hipokryzji nie widzę. Co do kompilatorów, chodziło mi o projekty domowe.
« Ostatnia zmiana: Lipiec 25, 2014, 00:16:21 wysłana przez Xirdus »

Offline Krzysiek K.

  • Moderator
    • DevKK.net

# Lipiec 25, 2014, 03:56:25
Cytuj
auto oznacza dedukcję typu, m_ składową klasy. Żadnej hipokryzji nie widzę.
Chodziło mi o to, że auto jest jednym z lepszych zaciemniaczy kodu - jak nasączysz kod "auto", to momentami trzeba trochę zamyślenia żeby dojść do tego, które zmienne są jakiego typu. A że poza szybszym pisaniem pozytywnych aspektów nie widzę, to osobiście staram się tego udogodnienia unikać. :)

Cytuj
Co do kompilatorów, chodziło mi o projekty domowe.
Tutaj to generalnie się zgadzam, tyle że czasem też szkoda czasu na instalacje nowego środowiska (sam siedzę na VC++ 2010).

Offline Xirdus

  • Redaktor

# Lipiec 25, 2014, 09:10:29
Chodziło mi o to, że auto jest jednym z lepszych zaciemniaczy kodu - jak nasączysz kod "auto", to momentami trzeba trochę zamyślenia żeby dojść do tego, które zmienne są jakiego typu. A że poza szybszym pisaniem pozytywnych aspektów nie widzę, to osobiście staram się tego udogodnienia unikać. :)

Przesadzasz z tą nieczytelnością. Ale w sumie ciebie rozumiem; osobiście stosuję auto tylko dla iteratorów i range forów - jak będzie C++14 to jeszcze w parametrach lambd będę, bo obecnie to jakaś porażka jak się używa algorytmów STL.

Offline yurai

  • Użytkownik

  • +3
# Lipiec 25, 2014, 15:04:57
Cytuj
Dzięki wielkie za odpowiedz. Czy mógłbyś mi w takim razie doradzić gdzie znaleźć jakieś dobre materiały na ten temat?

Chętnie też dowiem się jak inni tworzą swoje renderery :)

Mozesz podejrzec sobie jak to wyglada w przypadku silnika Ogre. Ogre jest teraz mocno przebudowywany (do wersji 2.0) tak by moc konkurowac z innymi render-erami pod wzgledem wydajnosci. Jeden z gosci ktory czuwa nad tym procesem udostepnil swego czasu slajdy bedace takim high levelowym diff-em miedzy tym co jest a tym co bedzie. Sporo miejsca poswiecil wlasnie architekturze. IMO cala prezentacja jest szalenie ciekawa i kazdy kto pisze silnik i chce to zrobic dobrze powinien do niej zerknac.

Link: http://www.mediafire.com/view/?7k0q4guxgm74y2g
Thread na forum: http://www.ogre3d.org/forums/viewtopic.php?f=25&t=75459