Pokaż wiadomości

Ta sekcja pozwala Ci zobaczyć wszystkie wiadomości wysłane przez tego użytkownika. Zwróć uwagę, że możesz widzieć tylko wiadomości wysłane w działach do których masz aktualnie dostęp.


Wiadomości - zarius

Strony: [1] 2 3 4 5 ... 13
1
Matematyka i fizyka / Problem z fizyka samochodu.
« dnia: Listopad 19, 2011, 18:03:46 »
Witam,

Pisze sobie wlasnie fizyke pojazdu do gry i mam nastepujacy problem.

Od razu dodam, ze korzystam z tego tutoriala: http://regedit.i365.pl/Mirror/Car%20Physics%20for%20Games/Car%20Physics%20for%20Games.html

Problem polega na tym, ze zmiana biegu na wyzszy powoduje spadek obrotow silnika (co jest normalne) ale powoduje tez spadek momentu obrotowego, co za tym idzie spadek ogolnej mocy silnika ktorej uzywam do wyliczania akceleracji.

Ta ze wzgledu na dzialajace sily oporu powietrza staje sie ujemna i auto zamiast na wyzszym biegu nabierac predkosci to ja traci.

Czy ktos kiedys uzywal powyzszego opisu do tworzenia symulacji fizycznej auta i czy mial podobny problem?

Siedze juz na tym tyle czasu, kombinuje na rozne sposoby i nie moge sprawic aby to zadzialalo jak nalezy.

Jesli ktos moglby pomoc to zamieszczam tez fragment kodu odpowiedzialny za wyliczanie obrotow silnika/momentu obrotowego i update ruchu:

void DoPhysics(float dt)
{
UpdateDrag(); UpdateFriction();

// Calculate drive wheel Angular Velocity.
AngularVelocity = GetWheelAngularVelocity(dt);
//AngularVelocity = Speed / WheelRadius;
// Plug-in to calculate engine RPM.
RPM = GetRPM(AngularVelocity); //CalculateRPM(AngularVelocity);
// Use RPM to get the engine Torque.
EngineTorque = Throttle * m_engine.GetTorque(RPM);

Direction = Vec2(-sinf(Rotation), cosf(Rotation));

float CrankshaftMultiplyer = GearRatios[CurrentGear] * DifferentialRatio;
DriveTorque = EngineTorque * CrankshaftMultiplyer * TransmissionEfficiency;
DriveForce = Direction * (DriveTorque / WheelRadius);

// Update Traction force taking Dynamic Weight Transfer into account.
UpdateAxlesWeight();
if(RearAxleWeight*TyreFrictionCoefficient < DriveForce.y)
TractionForce = Direction*RearAxleWeight*TyreFrictionCoefficient;
else
TractionForce = DriveForce;

float sign = fast_sign(TractionForce.y);

LongtitudinalForce = sign * D3DXVec2Length(&TractionForce)  + (-Direction.y)*(DragForce + WheelFrictionForce);

Acceleration = LongtitudinalForce / Mass;

// Hack ?
if(Acceleration <= 1.0f*D3DX_16F_EPSILON && Acceleration >= 1.0f*D3DX_16F_EPSILON)
Acceleration = 0.0f;

//float WheelRPM = RPM / CrankshaftMultiplyer;
//float RevolutionDisplacement = 2.0f * D3DX_PI * WheelRadius;
//float WheelRotationsPerSecond = WheelRPM / 60.0f;
//float WheelMetersPerSecond = WheelRotationsPerSecond * RevolutionDisplacement;

//if(Speed > WheelMetersPerSecond)
// Speed = WheelMetersPerSecond;

Speed += Acceleration * dt;

Position += Direction* Speed * dt * 10.0f;

}

float GetWheelAngularVelocity(float dt)
{
float TractionTorque = TractionForce.y * WheelRadius;
float TotalTorque = TractionTorque + EngineTorque*GearRatios[CurrentGear] * DifferentialRatio * TransmissionEfficiency;
AngularAcceleration = TotalTorque / AxleInertia;

AngularVelocity += AngularAcceleration * dt;

if(Speed/WheelRadius > AngularVelocity)
AngularVelocity = Speed / WheelRadius;

return AngularVelocity;
}

float CalculateRPM(float wheelAngularVelocity)
{ // Calculates the RPM from wheel angular velocity.
float rpm = wheelAngularVelocity * GearRatios[CurrentGear] * DifferentialRatio * 60.0f / (2.0f*D3DX_PI);

if(rpm < 1000)
rpm = 1000;

return rpm;
}

2
DirectX / Odp: [DirectX 9] Render targety a kanał alpha.
« dnia: Październik 13, 2011, 04:41:27 »
Wydawalo mi sie, ze jasno sformulowalem pytanie. Nie pytalem o porady na temat tego czy mam, czy nie mam uzywac rysowania do tekstury do osiagniecia tego co chce osiagnac. Mam swoje powody. Pojawil sie pewien problem i pytalem jak mozna to rozwiazac.

Nie chce mi sie wdawac w dywagacje na temat slusznosci rozwiazan ktore stosuje.

Tak czy siak, troche googlowania i w koncu znalazlem swoja odpowiedz.

Tak jak myslalem, alpha blending jest wykonywany dwa razy, dlatego jest problem z alpha. Rozwiazaniem jest PMA ktory nadaje sie do kompozycji transparentnych obiektow.

3
DirectX / Odp: [DirectX 9] Render targety a kanał alpha.
« dnia: Październik 13, 2011, 00:32:25 »
Tekst to jest jeden przyklad i nie jest kompletnie zwiazane z problemem. Rendering do tekstury gdzie bede potrzebowal alphe i wyjdzie podobny scenariusz mam chociazby przy GUI.

4
DirectX / Odp: [DirectX 9] Render targety a kanał alpha.
« dnia: Październik 12, 2011, 23:23:46 »
Albo jestem slepy, albo nie widze przycisku Edytuj. Jesli to pierwsze to z gory przepraszam.

Chcialem tylko dodac, ze chyba zaczynam domyslac sie skad bierze sie problem.

Scena jest renderowana z quadow do tekstury uzywajac alphy i w ten sposob piksele sa mieszane z tlem stajac sie na tyle transparentne na ile wynosila wartosc alphy dla danego piksela. Nastepnie rysujac taki render target z alpha te same piksele ponownie sa mieszane z ostatecznym obrazem i tak jakby kanal aplpha uzywany jest na tych pikselach dwukrotnie.

Dlatego piksele ktore oryginalnie byly calkowicie biale w tym przypadku pozostaly dalej biale, a kazdy piksel z chociaz odrobina transparetnosci zostal wyrenderowany dwukrotnie z alpha.

Czy to co pisze ma sens ? Jesli tak czy mozna cos z tym zrobic ? Bo poki co jedyny pomysl jaki mi przychodzi do glowy to uzywac innego shadera do renderowania do tekstury, a innego do renderowania ostatecznej sceny w ktorej to recznie przemnazalbym alphe przez *2.

Jest inny sposob ?

5
DirectX / [DirectX 9] Render targety a kanał alpha.
« dnia: Październik 12, 2011, 22:37:50 »
Szanowni Panstwo!

Otoz, mam nastepujacy problem. Jesli chodzi o sam rendering "sceny" do tekstury i jej wyswietlanie to jest ok. Kanal alpha niby tez jest prawidlowo ustawiany w pixel shaderze... no wlasnie - "niby".

Mam teksture w formacie png z kanalem alpha z poszczegolnymi glyphami fontu. Nastepnie w programie renderuje tekst do tekstury (moj render target) w formacie A8R8G8B8. Tekst jest oczywiscie w postaci oteksturowanych quadów.

Caly taki blok tekstu na teksturze nastepnie wrzucam na quada i renderuje do back buffera. Problem polega na tym, ze literki sa jakby poobgryzane. Jakby cos bylo nie tak z kanalem alpha.

Kiedy wyrenderowalem tekst bezposrednio do backbuffera (z oteksturowanych quadow) i nizej dla porownania teksture do ktorej renderowalem to widac problem ewidetnie. Zrzut i wersja z przyblizeniem w zalaczniku.

Jak sobie z tym poradzic ? Bo nie mam juz glowy do tego czemu sie tak dzieje.



6
Grafika 2D / Odp: fajne bitowe fonty, szukam (8x8 albo cos kolo tego)
« dnia: Październik 03, 2011, 00:23:51 »
Mozesz sprobowac uzyc biblioteki FreeType do rasteryzacji fontow TTF do tekstury tak jak to robia wyzej wymienione narzedzia do "produkcji" fontow bitmapowych. Rysujac je na oteksturowanych quadach pozwalalo by na osiagniecie roznych efektow, gradientow i tak dalej. Oczywiscie jesli chodzi o kopiowanie pikseli etc to wlasnie ten rasteryzator fontow umozliwia rowniez i takie zastosowanie. Ogolnie mozliwosci masz bardzo duzo bo fontow TTF z darmowa licencja w necie jest multum a napisanie sobie kilku klas do opakowania tej biblioteki to dzien roboty (przy moim slimacznym tempie pracy)

Dodatkowo warto uzyc takiego rozwiazania dla przyszlych projektow bo biblioteka ta latwo pozwala na rasteryzacje z anti-aliasingiem, obrysowaniem i innymi efektami.

7
C# / Odp: określenie pozycji z jakiejś klasy [XNA]
« dnia: Czerwiec 06, 2010, 19:58:39 »
Ale funkcja oczekuje argumenty Texture2D a nie Sprite dlatego musisz sie odwolac do skladowej klasy Sprite ktora jest typu Texture2D w tym przypadku jest to mSpriteTexture

Najprosciej bylo by po prostu wywolac mStatekSprite.Draw(); tam gdzie potrzebujesz narysowac statek

8
C# / Odp: określenie pozycji z jakiejś klasy [XNA]
« dnia: Czerwiec 06, 2010, 19:31:01 »
spriteBatch.Draw(mStatekSprite.mSpriteTexture, mStatekSprite.Position, Color.White)
Zalecam jednak nauczyc sie porzadnie C# bo tak jak ktos wyzej napisal to sa bardzo proste bledy. Wlasciwie kompilator wskazuje gdzie jest problem.

9
C# / Odp: określenie pozycji z jakiejś klasy [XNA]
« dnia: Czerwiec 06, 2010, 19:01:05 »
Zamiast

Rectangle statekRectangle =
               new Rectangle((int)mStatekSprite.Position.X, (int)mStatekSprite.Position.Y,
               mStatekSprite.Width, mStatekSprite.Height);

sprobuj:

Rectangle statekRectangle =
               new Rectangle((int)mStatekSprite.Position.X, (int)mStatekSprite.Position.Y,
               mStatekSprite.Size.Width, mStatekSprite.Size.Height);

A trzeci blad:
spriteBatch.Draw(mStatekSprite, mStatekSprite.Position, Color.White)

zamiast samego Position.

Generalnie to proponuje najpierw poczytac ksiazke o samym C# i dobrze to zrozumiec, potem bawic sie w XNA.

10
Szkółka / Odp: Własny GUI
« dnia: Październik 16, 2007, 16:57:27 »
Nie mam czasu czytac calego topicu przeczytalem tylko pytanie i napisze odpowiedz jak ja to kiedy mialem u siebie.

Otoz na podaym przykladzie ten gadzet jak kolwiek by nie wygladal i czegokolwiek by tam nie posiadal ma jako takiego input boxa co sie za tym wiaze ten ma jakas wartosc. U mnie kazda taka kontrolka (czy tam jej obiekt) miala metode Value ktora zwracala aktualna wartosc.

Jak teraz trzymac ta zmienna jak pisales aby byla aktualna ? Po prostu uzywajac zdarzen, czyli swojego rodzaju delegatow wywolywanych w odpowiednim momencie.

Jesli jest wprowadzana nowa wartosc do kontrolki (co napewno kontrolka powinna wiedziec) to odpala wlasciwy event w tym wypadku OnValueChanged a do tego mozemy podpiac nasza funkcje w ktorej to zrobimy zwykle przypisanie w stylu naszaPrzechowywanaWartosc = kontrolka.Value();

W ten sposob mozna zbudowac cale GUI i nie ma zadnego problemu z jego czytelnoscia czy zrozumieniem.

Piszac swoje graficzne GUI wzorowalem sie na tym jak to po czesci jest zrobione w Windows.Forms i mysle, ze na dzien dzisiejszy nic wygodniejszego nie wymyslono przynajmniej jesli chodzi o naturalnosc uzycia, a kod takiego czegos pisze sie bardzo szybko.

11
Design / Odp: MMORPG, w którym światem rządzą gracze.
« dnia: Wrzesień 16, 2007, 15:13:18 »
Jak to przeczytalem to jest to prawie, ze kalka mojego pomyslu z przed ponad roku. Nigdzie o nim nigdy nie pisal wiec jest to z cala pewnoscia taki zbieg okolicznosci ; Aczkolwiek swoj pomysl rozpisalem znacznie szerzej i widze minimalne roznice.

Dlatego oczywiste wydaje sie, ze pomysl mi sie podoba ;p

12
Projektowanie kodu / Odp: Model silnika
« dnia: Wrzesień 01, 2007, 22:38:10 »
Dlatego ja rowniez napisalem ze dla mnie mozliwosc podpiecia osobnych rendererow to jest jakas tam cecha a nie cel priorytetowy i narazie nie mam zamiaru pisac nic w ogl, wszystko co bede kodzil bedzie dzialac na Dx'ie co prawda z wlasnym interfejsem nad Dx'em, ale daje mi to mozliwosc pozniejszego ew. napisania tego pod OGL'em.

A po co komu 2 renderery ? W sumie to niby nie potrzebne ale moze przeportowanie np jakiejs gotowej aplikacji opartej o silnik pozniej na linuksa bedzie prostsze ? W sumie mono implementuje juz znacza czesc .NET wiec i #OGL mysle ze pod linuksem dzialal by jak znalazl. Nigdy sie w to nie zaglebialem ale taka mozliwosc byla by calkiem atrakcyjna ;d

13
Projektowanie kodu / Odp: Model silnika
« dnia: Wrzesień 01, 2007, 17:25:55 »
albo wprowadzic jakis interface dla VB ktory bedzie uzywany w calej aplikacji a nastepnie jak chcesz podpiac jakies api to po prostu dziedziczysz z tego interface'u i implementujesz poprzez dane API. Takich klas bedzie oczywiscie wiecej.

Dokladnie tak to sobie wyobrazam. Ogolnie narazie "renderery" upakowalem w jednym dll (co prawda na dzien dzisiejszy ich mozliwosci sa jeszcze zerowe) z podzialem na namespace jak Dx9 Dx10 OGL etc i wszystko oparte jest o jeden wspolny interfejs, a to jak zarzadzane jest w srodku zajmuje sie juz klasa wyprowadzona.

a do post processingu to mi jeszcze daleeeko takze tym sie jeszcze zupelnie nie zajmowalem. Niestety ale prawie zawsze dochodzi do momentu kiedy cos zaczyna sie kielbasic i trzeba wprowadzac zmiany "w modelu" aplikacji tak aby bylo elastycznie i bez zbednego mieszania. Jak zaczne pisac te trudniejsze aspekty (zapewne zwiazane z tymi Rendererami) to bedzie trzeba iteracyjnie problemy rozpracowywac ;d

Tak jak ktos napisal, zrodla Irrlichta i Ogra moga byc przydatne. Nie przygladalem sie tym C++'owym ale wersje C# tych silnikow przegladalem i mysle ze w razie problemow beda dobrym zrodlem odpowiedzi ;d

W sumie wszystko co zwiazane z renderowaniem wymagac musialo by takiego "dziedziczenia". Moja znajomosc OGL'a jest bliska zero, dlatego tez feature z kolejnymi rendererami pozostaje narazie "mozliwoscia" a nie czyms priorytetowym.

14
Projektowanie kodu / Odp: Model silnika
« dnia: Wrzesień 01, 2007, 04:30:40 »
Ja osobiscie mam cos pomiedzy rozwiazaniem novo a Koshmaara, co prawda jest to C# ale obiektowosc i koncepcje sa aktualne dla kazdego jezyka ;d. Uzywam co prawda dziedziczenia, ale nie po obiekcie silnika czy czyms takim. Mam odseparowane cos, co nazywam frameworkiem od pozostalych modulow.

Wyglada to tak:

Framework zawiera glowny obiekt reprezentujacy silnik i jego interfejs i jest to klasa hermetyczna. Klasa nazywa sie Manager. Mam rowniez interfejs o nazwie IFrameworkService po ktorym dziedziczy kazdy modul jaki zamierzamy uzyc w silniku. Mozna go podpiac dzieki temu do managera i potem jednym callem (manager jest dostepny globalnie) mozemy miec dostep do roznych modulow ktore moga byc pisane przez usera bez ingerencji w kod frameworka.

Manager ma "wbudowane" takie dwa moduly juz od poczatku, ale zajmuja sie tylko obsluga okna i czyms jeszcze co nazywam StateQueue czyli kolejka stanow.

Teraz piszac jakakolwiek aplikacje mozna z cala pewnoscia wyodrebnic rozne stany. Czy to splashscreen, menu czy tez sama gra. Dlatego tez zastosowalem rozwiazanie dziedziczenia po klasie "State".

Nie ma za wiele wspolnego z samym silnikiem i jako taka nie ma dostepu do niczego ;d Klasa wyprowadzona ze state po prostu musi zaimplementowac metody takie jak Update, Render etc.

Tutaj wystepuje jakies tam podobienstwo do kodu Koshmaara z tym, ze sam stan nie zajmuje sie niczym poza soba ;d

Poruszajac jeszcze sprawe elastycznosci, w moim aktualnym projekcie (pisze go dopiero 3 dzien) odstapilem od poprzedniego "sposobu" pisania i nie robie wszystkiego "na sztywno" pod jedno api, wiec musialem dokonac kolejnych przerobek w tym moim "frameworku". Manager musi zostac powiazany z jakims rendererem (klasa musi implementowac interfejs IRenderer) a Renderer jako mozna sie domyslec jest rowniez kolejnym dzieckiem "IFrameworkService". Dlatego moge w latwy sposob bez dotykania czegokolwiek dopisac nowy kod uzywajac innego api do 3d.

To chyba na tyle tego przydlugiego opisu. Z tego co przegladam to jednak widze ze wszystkie koncepcje sa dosyc bliskie sobie i jak by sie tego nie zrobilo to pewnie bedzie dobrze ;d

15
Językoznawstwo / Odp: Managed (C++ vs C#)
« dnia: Sierpień 29, 2007, 04:58:22 »
Rozwodzenie sie nad faktem czy MC++ czy tez C++/CLI mialby byc szybszy od C# z wykorzystaniem XNA nie ma najmniejszego sensu z prostej przyczyny - XNA nie wspiera innych jezykow i przynajmniej przez jakis czas tego nie bedzie robic.

Strony: [1] 2 3 4 5 ... 13