játékfejlesztés.hu
FórumGarázsprojectekCikkekSegédletekJf.hu versenyekKapcsolatokEgyebek
Legaktívabb fórumozók:
Asylum:    5468
FZoli:    4892
Kuz:    4455
gaborlabor:    4449
kicsy:    4304
TPG:    3402
monostoria:    3284
DMG:    3172
HomeGnome:    2919
Matzi:    2524

Pretender:    2498
szeki:    2440
Seeting:    2306
Geri:    2193
Orphy:    1893
Joga:    1791
Bacce:    1783
MaNiAc:    1735
ddbwo:    1654
syam:    1491
Frissebbek | Korábbi postok
[1] [2] [3] > 4 < [5] [6] [7] [8] [9] [10] [15] [20] [25] [30] [35] [40] [45] [50] [55] [56]
Instalok - Tag | 571 hsz       Online status #209693   2016.05.29 20:05 GMT+1 óra  
Gondolom sikerült valami új bugot belerakniuk. Mióta újratelepítettem a gépet, nem volt egy értelmesen, jól működő Unity editorom. Az 5.0 változat óta csak egyre szarabb és szarabb. Random kifagy, elcrashel, vagy nem csinál semmit, csak bezáródik. Vagy éppen csak behal a buildelésbe, és úgy lelockolja a file-okat, hogy újra kell indítanom a gépet. Szóval szerintem amíg editorban nem megy csak, addig ne foglalkozz vele, max. tolj egy bugreportot.

   
Tunyu - Tag | 449 hsz       Online status #209692   2016.05.29 19:37 GMT+1 óra  
Valakinek van ötlete mitől lehet az, hogy korábban ami jól működött több szálon a szerkesztőben is, az most valami oknál fogva a szerkesztőben csak egy szálon fut, viszont a kész programban továbbra is jól működik több szálon.Ha indítok egy új szálon egy folyamatot, akkor a fő szálat addig felfüggeszti amíg be nem fejeződik. Threadpool-nál is hasonló a helyzet, csak egyetlen egy szálon futtatja az összes indított folyamatot. Igazából annyiban zavar a dolog hogy mindig újra kell építenem hogy lássam jól működnek a dolgok.

   
Instalok - Tag | 571 hsz       Online status #209569   2016.05.10 15:12 GMT+1 óra  
Olyan, mint egy néhány lépéses Radial Blur. Lehet olyan post-process shadert írni Unity-hez, ami ilyesmit csinál, nem olyan túl nehéz. Fogod a jelenetet, mint textúrát, és kicsit offsetelve újra és újra olvasod, majd összeadogatod súlyozva.

Ha itt kicsit lentebb tekersz, valaki mintha írt volna megoldást is.

   
Tibsy - Tag | 307 hsz       Online status #209568   2016.05.10 15:00 GMT+1 óra  
Tudja valaki,hogy lehet ilyen effectet csinálni mint ami a képen is be van jelölve (szellem kép ) ?
   
Lord_Crusare - Törzstag | 1309 hsz       Online status #209479   2016.04.18 20:07 GMT+1 óra  
Nekem PC-n nem volt hajlandó full HD videót nézhető sebességgel lejátszani, és nem hardver gondok miatt, azt elhiheted.

   
Tunyu - Tag | 449 hsz       Online status #209478   2016.04.18 19:50 GMT+1 óra  
Az tény hogy elég magas az erőforrás igénye,de feltételezem hogy nem full HD video lejátszására tervezték.Egy HD videót simán lead 60 fps-el erőlködés nélkül, nem beszélve arról hogy bármilyen objektumot textúrázhatsz a videóval.Nincs egy erőgépem, de egy full HD videót nekem lejátszott 30-40 fps-el, persze a háttérben nem futott sok alkalmazás, a processzor 80-90% ment a gpu meg 99%-on.Azt nem állítanám hogy használhatatlan, de igényel némi kompromisszumot.
Video adaturation : 3mn 44s
Bit rate : 4 026 Kbps
Width : 1 920 pixels
Height : 1 088 pixels
Original height : 1 080 pixels
Display aspect ratio : 16:9
Original display aspect rat : 16:9
Frame rate mode : Constant
Frame rate : 25.000 fps

   
Lord_Crusare - Törzstag | 1309 hsz       Online status #209470   2016.04.18 11:08 GMT+1 óra  
A Meridian: Squad 22 full HD átvezetőit borzalmas minőségben és 10-15 FPS körüli sebességgel volt csak hajlandó lejátszani.

   
Tunyu - Tag | 449 hsz       Online status #209469   2016.04.18 10:49 GMT+1 óra  
Ezt miért mondod? Tökéletesen működik! Én régebben tesztelgettem és még most is működik.Közben rájöttem hogy a Quicktime csak a videó konvertáláshoz kell, a lejátszáskor már nem szükséges.

   
Lord_Crusare - Törzstag | 1309 hsz       Online status #209468   2016.04.18 10:01 GMT+1 óra  
Szerintem semmikor. A Unity beépített video lejátszása egyébként is használhatatlan.

   
Tunyu - Tag | 449 hsz       Online status #209466   2016.04.18 08:04 GMT+1 óra  
Vajon mikor reagál erre a Unity!? Ez a Unity video lejátszáshoz szükséges.

   
varganorbert222 - Tag | 8 hsz       Online status #209463   2016.04.16 23:28 GMT+1 óra  
Igen, igen amint elküldtem a hozzászólást rá is jöttem, hogy mekkora marhaságot írtam csak mondom már mindegy...
Lényeg a lényeg, hogy a koncepciódat alapul véve már ki is ötlöttem a megoldást. Hasonlóan lesz egy GO aminek a gyereke a kamera, majd csak a gyereket fordítom rá. Így a pozíció maradhat a szokásos vektoros megoldás, és rotation meg csak a gyereké lesz. Így a forward, right vektor is úgy marad, ahogy nekem kell.
Ja és köszi az ábrát, szeretem, ha van ábra.

De nyugodtan megoszthatod a további gondolataidat! Mindig tanul az ember és szeretem a frappáns megoldásokat.

   
Instalok - Tag | 571 hsz       Online status #209462   2016.04.16 23:07 GMT+1 óra  
Az a baj, hogy ha magára a kamerára teszed a scriptet, akkor, ha forgatod, akkor olyan, mintha "balra néznél", nem olyan, mintha elmennél jobbra és úgy néznéd az objektumot. Vagy hogy is mondjam. Szóval mivel magának a game objectnek a forgatását változtatom, és annak a gyereke a kamera, így az mozog vele együtt.

Na, csináltam egy csodálatos képet.

Szóval, az első esetben, a GO-n van a script, azt pozicionáljuk és forgatjuk. Ami azt eredményezi, hogy a hozzá képest eltolt kamera, ami a gyereke, mozog vele együtt, így nem kell a kamerával ténylegesen foglalkozni.
A második eset pedig azt szemlélteti, hogy ha csak simán a kamerán van a script, akkor ott a forgatás csak annyit eredményez, hogy "elnéz a kamera" más felé. Ha ugyan azt szeretnénk megoldani, mint az 1. esetben, akkor külön kell megoldani a pozicionálást is. Ami persze nem olyan borzasztóan nagy munka, csak hát minek.

   
varganorbert222 - Tag | 8 hsz       Online status #209460   2016.04.16 22:01 GMT+1 óra  
Igen láttam, de sztem az sem fontos, hogy úgy legyen. Mivel a child lokálisan nem változik, a parent globálisan igen, tehát a repülőhez viszonyítva csak a parent számít magyarul a script lehetne magán a kamerán is.
De amint géphez ülök átvizsgálom a dolgot.
Az Eulerangles eszembe se jutott amúgy, pedig pont ez megoldás. Mégegyszer thx!

   
Instalok - Tag | 571 hsz       Online status #209459   2016.04.16 21:52 GMT+1 óra  
Annyi a trükk igazából, hogy nem konkrétan a kamerát forgatom meg pozicionálom, hanem egy sima objectet, aminek a gyereke a kamera, de gondolom ezt látod úgyis. Nyilván van más fajta megoldás is, nekem így este ez ugrott ki a fejemből.

   
varganorbert222 - Tag | 8 hsz       Online status #209458   2016.04.16 21:36 GMT+1 óra  
Oh köszönöm szépen, pont ilyenre gondoltam!
Ezzel már át tudom alakítani a kódomat.
Pacsi!

   
Instalok - Tag | 571 hsz       Online status #209457   2016.04.16 21:06 GMT+1 óra  
3257-arcade_camera.zip
Nézd meg, hogy így gondoltad-e valahogy a dolgot. Mármint, hogy jól értem-e az egészet. Ha igen, akkor ez egy nagyon kis primitív megközelítés, de jónak tűnik első körben.

   
varganorbert222 - Tag | 8 hsz       Online status #209456   2016.04.16 20:22 GMT+1 óra  
Oh tudom én mit írtam, és valóban jól látod. Az a helyzet, hogy mind a kettő.
Tehát felhasználja a repülő lokális tengelyeit, viszont amikor a repülőn forgatás történik a kamera ne másszon el vele, hanem maradjon az eredeti síkban mégis a repülő mellett a megfelelő oldalon, amit a billentyűvel "választasz" ki. Nem tudom, hogy érthető-e.
Szóval követi a lokális tengelyeit ugyan akkor globális szinten ott is marad, ha forog a repülő úgy, hogy végig követi az adott oldalt.

   
Instalok - Tag | 571 hsz       Online status #209455   2016.04.16 20:04 GMT+1 óra  
Egyébként:
Idézet
Ja, és nekem pont az lenne a lényeg, hogy ha a repülő forog maga a kamera pozíciója ne változzon hatására, maradjon relatíve a gép azon pontján mondhatni globálisan

A relatív és a globális itt ellentmond egymásnak. Szóval akkor most globálisan maradjon mindig ugyan ott, vagy ha fordul a repülő, akkor forduljon vele a kamera is? (Azaz maradjon a kamera a repülő jobb oldalán pl.)

   
varganorbert222 - Tag | 8 hsz       Online status #209454   2016.04.16 19:59 GMT+1 óra  
@Instalok:
Rendben, köszönöm szépen a segítséged!
Még a Transform.RotateAround()-ra gondoltam, de az is olyan macerás, még clampelni is kellene az angle-t, hogy ne forduljon tovább adott szögön túl stb stb... Valami egyszerű és a cpu számára gyors megoldás kellene.

   
Instalok - Tag | 571 hsz       Online status #209453   2016.04.16 19:36 GMT+1 óra  
Nyilván, ha fordul a kamera, akkor változik a transform.forward, ez csak természetes. Az up pedig azért nem változik, mert azon tengely mentén forgattad el a kamerát. Ha lesz egy kis időm, gondolkozok rajta, hogy hogy lehetne ezt egyszerűen megcsinálni, hacsak nem előz meg valaki.

   
varganorbert222 - Tag | 8 hsz       Online status #209452   2016.04.16 19:19 GMT+1 óra  
https://www.youtube.com/watch?v=hzz623DJzPE

A videó első 10 másodpercében pont látszik, amit szeretnék megvalósítani. Amint látható a gép 5 pontjára ugrik a kamera. Két oldalra, fel, előre és hátra. Nyilván a hátsó pont a follow az működik, illetve a felső pont is kifogástalan. Az oldalsó és az első pozíciókkal van a probléma. Ha Quaternion.Lookrotation() vagy Transform.Lookat() nélkül használom gond nélkül oda ugrik ahova kell, viszont ha közbeavatkoznak, akkor valamiért végtelen forgásba kezd a pozícióra írható kör kerületén, aminek a sugara számomra ismeretlen...
Arra gyanakszom, hogy a cameraRigidbody.transform.forward-ja nyilván megváltozik a rotation hatására és ennek a következménye, viszont erre meg rácáfol a transform.up pozíció, mert ott meg működik. Nem értem.
Ja, és nekem pont az lenne a lényeg, hogy ha a repülő forog maga a kamera pozíciója ne változzon hatására, maradjon relatíve a gép azon pontján mondhatni globálisan. Tehát a player.transform.forward és right-ra való hivatkozás szóba sem jöhet, azzal már csináltam, de nem úgy akarom.

   
Instalok - Tag | 571 hsz       Online status #209451   2016.04.16 13:15 GMT+1 óra  
Lehet, hogy másképp is meg lehetne közelíteni az egészet. Ha esetleg tudnál mutatni egy videót, hogy milyen kamerakezelést szeretnél, akkor lehet, hogy tudnánk módosítani picit a kódon.

   
varganorbert222 - Tag | 8 hsz       Online status #209450   2016.04.16 12:57 GMT+1 óra  
@Tunyu:
Az if else szerkezetnek pont az a szerepe, hogy egyszerre csak egy lehetőség értékelődjön ki, ezzel nincs is baj.
@Instalok:
Debugoltam mindent, amit lehet és nem kap sehol sem értelmezhetetlen értéket, vagy Zero Vector-t.

Továbbra is fenn áll a probléma... A nap folyamán prezentálom a jelenséget, amint lesz rá időm.
Előre is köszönöm a segítséget!

   
Instalok - Tag | 571 hsz       Online status #209448   2016.04.16 07:54 GMT+1 óra  
@varganorbert222:
Nem biztos, hogy teljesen jól értem, hogy mi a probléma. Esetleg próbálj meg debuggolni, és figyelni az értékeket. Nem lehet, hogy véletlenül a wantedRotation zero vector lesz?

   
Tunyu - Tag | 449 hsz       Online status #209447   2016.04.16 07:07 GMT+1 óra  
varganorbert222 :
A 3 else if kavar be szerintem! Csak az elsőt hajtja végre ha igaz, ezért kellene külön szedned a vertikális és horizontális ellenőrzést. if közvetlen lehet egymás után több is, de else if
csk egy, mjd végük egy else .

   
Viperion - Tag | 540 hsz       Online status #209446   2016.04.16 00:10 GMT+1 óra  
"Nyilván nem, mert kvaterniót használ a forgatáshoz, ott meg szépen előjön a floating point pontatlanság"
Elmagyarázod miért jön elő?

Utánajártam pár dolognak de nem vagyok biztos magamban.
Ha minden igaz a kerekítési hibák okozója abban van ahogy ábrázolva vannak a valós számok.
Fix az-az meghatározott számú bináris számot használ a rendszer arra,hogy reprezentáljon egy decimális számot. Viszont néhány decimális szám nem reprezentálható tökéletesen bináris formában és ennek eredménye az,hogy kis mértékű kerekítési hibák keletkeznek amik ha gondolom sokszor összeadódnak,összeszorzódnak, stb egyéb számoláskor végzett változásokon esnek át akkor ezek elég nagy mértéket ölthetnek ahhoz,hogy nem csak grafikai hibákhoz hanem akár bizonyos esetekben a legrosszabb az-az a program összeomlásához is vezethessenek.

Így már érthető számomra hogy egy projektnél ahol bizonyos objektumot tartani kell pontosan fixen valamihez pl a tetris objektumait a pályát alkotó rácsok méreteihez hát még szép hogy roundelni kell én meg azt hittem felesleges. Plusz arra is rájöttem, hogy melyek azok a problémás decimális számok és miért pont azok. Most már fényesen süt a nap!

Ezt a hozzászólást Viperion módosította (2016.04.16 01:41 GMT+1 óra, 918 nap)

   
varganorbert222 - Tag | 8 hsz       Online status #209445   2016.04.15 21:10 GMT+1 óra  
Sziasztok! Segítséget szeretnék kérni!
Egy egyszerű arcade repülős játékon ügyködöm. Épp a kamera kezelésért felelős dolgokat csinálom. A következőképpen működik:
Ha nem nyomsz meg semmilyen kamera gombot, akkor sima follow mód, ha vertikális vagy horizontális input érkezik a megfelelő gép körüli pontra ugrik, majd ráfordítja a kamerát.
Már egy ideje szenvedek vele, és az agybaj kerülget, hogy mi a fenéért nem jó. Külön-külön tesztelve működik a pozícióra ugrás, és a forgatás, viszont együtt már betesz neki valamiért. Az is érdekes, hogy a felső (kódban az első) kamera állás is jó, illetve a follow (kódban az utolsó a cameraFollow() előtt) is ugyanazon az elven van megvalósítva mégis probléma mentes. Tehát a képen a zölddel kijelölt részek működnek együtt, a pirosak már nem azt csinálják, amit szeretnék. Gyakorlatilag elkezd forogni a kamera körbe-körbe nagyon gyorsan és sokszor még a Unity is crashel...

   
FZoli - Szerkesztő | 4892 hsz       Online status #209444   2016.04.15 21:08 GMT+1 óra  
Megpróbálhattad volna jól megkérdezni is. Azt kérdezted miért kell, írja a bekezdés, azért kell, mert a koordináták a forgatás után már nem biztos, hogy kerek számok lesznek.
Én nem tudom neked kitalálni, hogy igazából mit akarsz kérdezni. Amíg nem szánod rá az időd a kérdésed jól feltenni, addig ne számíts kielégítő válaszokra sem.

és úgy érzem mintha hülyènek nèznèl teljesen

Hát azért adod is alám a lovat rendesen.
Egyébként szerintem a legjobbat azt teszem veled, ha elveszem a kedved a játékfejlesztéstől. Minél hamarabb kezdesz valami olyasmibe, amihez van tehetséged, annál jobb lesz neked is.

Ezt a hozzászólást FZoli módosította (2016.04.15 22:45 GMT+1 óra, 918 nap)
   
Harsh - Tag | 245 hsz       Online status #209442   2016.04.15 20:06 GMT+1 óra  
Nem tudom pontosan hogy számol, de matek. Ha valahol több tizedes jegy keletkezik, mint amit kezel, akkor nyilván kerekített értékkel számol tovább. Ha meg egy részeredmény kerekített, akkor nyilván az eredmény se fog tökéletesen jól kijönni. Kapásból ott a Pi. Valahol meg kell állnod. Végtelen tizedesjeggyel nem tudsz számolni. Szóval már itt bukott a dolog.

szerk:
Mondjuk jelen esetben nem lenne muszáj forgatni. Viszont a korrekció is egyszerű... szóval...

   
Viperion - Tag | 540 hsz       Online status #209441   2016.04.15 19:40 GMT+1 óra  
Számomra továbbra is teljes a sötétség.
Miért ilyen bonyolult.

Matzi így már érthetőbb. A te válaszod tudott hatással lenni az én kemény elmémre.
De egy valami még nem világos lentebb írták hogy 90 fokos elforgatás nem pont kilencvenfokos lesz de miért nem.
Ha elfordítom 90 fokba akkor miért nem ponr ennyit fordul?

Vagyis márt csak azt nem értem,higy mi az oka annak hogy egy elforgatás pontatlan lesz?

   
Matzi - Szerkesztő | 2524 hsz       Online status #209440   2016.04.15 19:37 GMT+1 óra  
Ha nem kerekíted az értéket, akkor elcsúsznak, ami azért nem jó, mert itt diszkrét helyek vannak, mondjuk 3. és 4. oszlop, nem pedig 3.002 vagy 2.998. Ha nem kerekítesz, akkor egy ido után a pontatlanságok osszeadódnak, és az elemed már nem ott lesz, ahol elvileg lennie kellene.
If your game idea starts with the story it’s not a game idea.
Stories in games are optional.
   
Instalok - Tag | 571 hsz       Online status #209439   2016.04.15 19:29 GMT+1 óra  
Nyilván nem, mert kvaterniót használ a forgatáshoz, ott meg szépen előjön a floating point pontatlanság. Elég sok benne a sin, cos meg a szorozgatás, összeadogatás.

   
Harsh - Tag | 245 hsz       Online status #209438   2016.04.15 19:24 GMT+1 óra  
Én ahogy most ránéztem csak szimpla helyreigazítás. Jó lenne nélküle is, csak amit használ is lejjebb trasnsform.Rotate(0,0,-90) az nem feltétlen 90fok-os elforgatás lesz tökéletesen. Tapasztaltam már ilyent.

   
Viperion - Tag | 540 hsz       Online status #209437   2016.04.15 19:09 GMT+1 óra  
Igen tudom:
We will need this function because rotations may cause the coordinates to not be round anymore

De ebből èn nemtudtam meg azt,hogy erre mièrt van szüksèg.
Mièrt volna baj az,ha nem kerekíteném az értéket ,ha èn ezt nemtudom akkor mègis hogy èrthetnè meg ebből a keveset mondó magyarázatból egy kezdő.
Ennyire tudok angolul fzoli ès azèrt ne néz ennyire hülyének hogy nem olvasom el a tutorialban rendesen ami oda van írva.
Nagyon sértő ez szàmomra és úgy érzem mintha hülyènek nèznèl teljesen, egyébként pedig abból hogy a tutorial leírás alapján nem értettem meg mègis hogyan gondolhattad hogy nem olvastam el amit bemásoltál ide onnan? Tudod lètezik olyan,hogy valami hiába van kifejtve mègsem èrti az ember. Ekkor van szüksèg egy nagy segítségre.

Bocsi a szúrós válaszom miatt de nagyon úgy érzem hogy tehetetlen hülyènek nèzel mikor ez nem igaz. És az,hogy ez nem igaz abból is látszik hogy nem egyből ide írkálok ki hanem nézek tutorialokat,olvasom mások kérdéseit stb.

Kèrlek segíts vagy inkább ne írj ha nem akarsz mert a válaszod az hogy bemásolsz onnan ide abból a tutorialból az nem vehető szerintem segítségnek. Ez csak arra jó,hogy kezdegess.

   
FZoli - Szerkesztő | 4892 hsz       Online status #209436   2016.04.15 18:34 GMT+1 óra  
Írja a bekezdésben.

We will need this function because rotations may cause the coordinates to not be round anymore.
   
Viperion - Tag | 540 hsz       Online status #209434   2016.04.15 18:21 GMT+1 óra  
Ebben a tetris tutorialban mièrt van szüksèg arra hogy kerekítsen a vector adattagjain?
http://noobtuts.com/unity/2d-tetris-game
Kód:
  public static Vector2 roundVec2(Vector2 v) {
    return new Vector2(Mathf.Round(v.x),
                       Mathf.Round(v.y));
}         


Ezt mièrt kell?

   
frogbonegames - Tag | 74 hsz       Online status #209172   2016.03.11 19:27 GMT+1 óra  
Sziasztok,
ha valahol, mondjuk valós idejű stratégiában arra van szükségem, hogy legyenek légi egységek is, arra van valami jó best practice, hogy ne kelljen útkeresést írni?

A probléma ugye az, hogy a navmeshagenteknél nem beállítható, hogy "repüljön", viszont amúgy meg jó lenne a navmeshagenteket használni arra, hogy a repülő egységek egymást kikerüljék?

Amúgy a problémát - elég sajátos módon - megoldottam, kell egy plane a terrain felé, bake-elem a navmesht, és kész , de érdekelne hogy van-e valami jobb megvalósítás, internetet böngészve nem találtam megfelelően tiszta megoldást, bár biztos van valahol ilyen.

   
Matzi - Szerkesztő | 2524 hsz       Online status #209171   2016.03.10 10:22 GMT+1 óra  
Azét nincs ra gyorsabb mód, mert nem szokás ilyet csinálni. Egyes rendszerek tudnak olyat, hogy bizonyos ero térfogatokat alkotnak, ami a rendszeren belul optimális sebességgel tud mukodni. Ha ilyen nincs, akkor jobb ha kihagyod.
If your game idea starts with the story it’s not a game idea.
Stories in games are optional.
   
Viperion - Tag | 540 hsz       Online status #209169   2016.03.09 19:46 GMT+1 óra  
Igen pont ez jutott az eszembe koràbban.
Ezt mèg a te kommented előtt ki írtam a gyikon.
http://www.gyakorikerdesek.hu/szamitastechnika__programozas__7638987-unity3dben-egy-particle-effectet-alkoto-spriteokat-nem-mindet-hogyan-gyujthet

Ahogy te is írtad ez nem szèp ès nem gyors. A problèma az,hogy nem talàlok megoldàst egy gyorsabb alternatív megoldàsra. :-(

Kerestem tegnap este is megoldàsok utàn de semmi. Úgy tűnik muszàj lesz úgy megoldani ahogy te ès èn is màr kitalàltuk. De akkor jobb volna többszàlon futtatni vagy pedig ezt a rèszt c++ ban írni sőt c++ ban ès többszàlon. Ha jól gondolom pont az ilyen prociigènyes dolgok miatt van az hogy lehet c++ kódot is futtatni dll ben. Majd import ès futtatàs. De jó hogy van nèmi c++ múltam thx god.

De azèrt jó volna még pàr ötlet. Tudom,hogy vannak it zsenik!

Ezt a hozzászólást Viperion módosította (2016.03.09 20:04 GMT+1 óra, 955 nap)

   
Matzi - Szerkesztő | 2524 hsz       Online status #209160   2016.03.09 00:12 GMT+1 óra  
Érdemes elolvasni az API-t, vagy rákeresni a neten. Az ilyesmi amúgy nem szép és nem gyors, szóval ha csak teheted inkább keruld el.

http://docs.unity3d.com/ScriptReference/ParticleEmitter-particles.html
http://docs.unity3d.com/ScriptReference/Particle.html

A particle emitteren keresztul el tudod érni az osszes megkreált részecskét a particles néven. Azokon végigmehetsz egyesével, kiszurve azokat, amik elég kozel vannak a forráshoz. Aztán ahogy nézem a velocity tulajdonságot érdemes módosítani.
If your game idea starts with the story it’s not a game idea.
Stories in games are optional.
   
Viperion - Tag | 540 hsz       Online status #209155   2016.03.08 12:02 GMT+1 óra  
Hogyan csinàlhatom meg azt hogy azok a rèszecske hatàst alkotó kèpek amelyek egy x sugarú körön belül vannak visszakaphassam őket egy tömbbe,hogy aztàn adhassak nekik egy addforcet. Overlapcircleall ezt a metódust hasznàlhatom valahogy erre a cèlra.

Tudnàtok egy pèlda kódot írni mert hiàba tudom megfogalmazni magamban lèpèsről lèpèsre hogy mit kell tenni de egyszerűen nem talàlok semmit az unityben ami ezt lehetővè tennè.

Azt akarom megvalósítani hogy van egy shuriken amit ha eldobok,akkor a shuriken àltal lètrehozott lègmozgàs egy picit arra az irànyba húzza a füst rèszecske bizonyos rèszeit amelyre a suriken repül. Az overlapcircleall -t tartalmazó script a shurikenen volna ès 3 sugarú körben szeretnèm ha visszaadnà a sugaron belül levő particlekat.

Ezutàn pedig ezeknek kène adni egy addforceot. De az addforce a fizika rèsze nem pedig a particleè. :-(

   
Zolee - Tag | 1 hsz       Online status #209102   2016.02.25 20:40 GMT+1 óra  
Sziasztok
Az mitől lehet hogy ha vertex snappingal egymáshoz illesztem a részeket,akkor elég gyakran olyan zizis lesz az illesztésnél,mintha nem jól illesztené egymáshoz.Ez ilyen,vagy nálam nem stimmel valami?Elvileg a részek pontosak,3dsmaxban pontosan rácshoz illesztettem,tehát egyformának kellene lenniük,nem szabadna közöttük résnek lennie.
Esetleg nem lehet érzékenységet vagy valamit állítani?

   
Viperion - Tag | 540 hsz       Online status #209043   2016.02.15 19:41 GMT+1 óra  

Ezt a hozzászólást Viperion módosította (2016.03.08 22:34 GMT+1 óra, 956 nap)

   
Tunyu - Tag | 449 hsz       Online status #209017   2016.01.31 18:07 GMT+1 óra  

Ezt a hozzászólást Tunyu módosította (2016.02.03 11:12 GMT+1 óra, 991 nap)

   
Viperion - Tag | 540 hsz       Online status #208987   2016.01.18 17:19 GMT+1 óra  
Pixi pont fordítva lett igaz. Függetlenül attól,hogy kevés vagy óriàsi mennyiségű objektel próbàlom az animation veri a scriptes módszert. Érdekes. És nem az atlaszos módszerre gondoltam.

   
Instalok - Tag | 571 hsz       Online status #208986   2016.01.18 13:47 GMT+1 óra  
Egyébként szerintem a beépített animációval gyorsabb lehet ez az egész, bár nem hiszem, hogy mérhető különbség lenne a két megoldás között.

   
Pixi - Tag | 206 hsz       Online status #208985   2016.01.18 11:55 GMT+1 óra  
Ja ezt akkor benéztem, mert nekem alapból a "sprite animation" jut eszembe, de ez azért van, mert én csak 2D-zek, és azt sem Unity-ben.

   
FZoli - Szerkesztő | 4892 hsz       Online status #208984   2016.01.18 06:20 GMT+1 óra  
Pixi: szerintem Viperion sem az atlaszolt animra gondolt.
   
Pixi - Tag | 206 hsz       Online status #208983   2016.01.17 21:36 GMT+1 óra  
Viperion: Szerintem gyorsabb, ha egy alakzatnak csak a méretét változtatod. Akkor csinálnak animációt (textúra atlaszt), ha a változtatni kívánt sprite tartalma változik. Így helyet is spórolsz vele. Ha csak nagyítani, kicsinyíteni kell, esetleg forgatni, akkor szerintem inkább scale, rotation a megfelelő megoldás. Ja és akkora spriteot csinálj, amiről tudod, hogy attól jobban nem fogod kinagyítani. Amúgy mindenképp tesztelned kell, hogy mennyit bír egy gyengébb hardver. Van egy bizonyos korlát, ami felett nem tud teljesíteni semmilyen trükközéssel.

   
Viperion - Tag | 540 hsz       Online status #208982   2016.01.17 02:43 GMT+1 óra  
Ha akarom ,hogy a sprite változtassa a méretét ez egy csillag,akkor teljesítmény szempontjából,hogy volna jobb megoldani mert rengeteget akarok gyengébb mobilra.

Most úgy van,hogy animálva van a csillag a scaleja van animálva összesen két másodperc alatt nagyobbodik és húzódik vissza majd kezdődik az elejétől. Egyébként csillagon kívül van még egy csomó objekt amivel hasonlóan akarok eljárni.

Az a rengeteg animáció egyidejű lejátszása nem lesz túl problémás szerintetek?
Vagy inkább le kéne futtatni egy ciklust az összes objektre ezen belül meg módosítanám a scalejukat. Vagy hogyan kéne csinálni?

Scripteljem le vagy maradjon az animáció vagy más?

   
Frissebbek | Korábbi postok
[1] [2] [3] > 4 < [5] [6] [7] [8] [9] [10] [15] [20] [25] [30] [35] [40] [45] [50] [55] [56]