Graphics completed
This commit is contained in:
parent
2c9db35fcc
commit
eb13264035
112
ch2.tex
112
ch2.tex
@ -79,7 +79,7 @@ Pro~přiblížení problému, vyjmenuji časté potřeby, které~vznikají při~
|
||||
Převážně pro~použití v~animacích je~implementována fronta rychlých interaktivních událostí (QTE - Quick Time Events), což~jsou~interaktivní UI~elementy na~obrazovce hráče. V~herním průmyslu jsou~využívány zejména v~cutscénách, pro~,,hlubší ponoření'' hráče do~děje. Klasickými příklady jsou~animace šplhání herní postavy po~nějaké překážce nebo~kinematografický souboj mezi postavami. Při~takových událostech lze~přiblížit hráče k~dynamické a~napínavé situaci pomocí klikání na~stejně dynamické UI~elementy na~obrazovce v~souladu s~pohybem herní postavy. V~praxi se~objevují i~pokročilejší varianty napodobení děje pohybem myší a~joystickem nebo~gyroskopem ovládače. V~implementaci jsou~k~dispozici eventy jednotného a~vícenásobného klikání a~držení tlačítka v~časovém intervalu.
|
||||
|
||||
\subsection{Dialogy}
|
||||
V~enginu je~zavádějící implementace pokročilého dialogového systému. Dialogy jsou~neintuitivní pro~tvorbu a~použití, vyžadují časté repetitivní kopírování stejných parametrů mezi~soubory dialogů a~k~tomu celý systém má~nedostatečnou dokumentaci. Navíc~,,dialogy'' v~tomto systému jsou~pouze samostatné věty, které~musí přehrávat nějaký zvuk a~mohou se~vybírat v~závislosti na~omezeném kontextu typu "kdo~na~koho mluví". O~nepoužitelností takového rozhraní svědčí návody na~tvorbu vlastních dialogů nebo~vývojářský obchod plný pluginů implementujících tento systém lépe.
|
||||
V~enginu je~zavádějící implementace pokročilého dialogového systému. Dialogy jsou~neintuitivní pro~tvorbu a~použití, vyžadují časté repetitivní kopírování stejných parametrů mezi~soubory dialogů a~k~tomu celý systém má~nedostatečnou dokumentaci. Navíc~,,dialogy'' v~tomto systému jsou~pouze samostatné věty, které~musí přehrávat nějaký zvuk a~mohou se~vybírat v~závislosti na~omezeném kontextu typu ,,kdo~na~koho mluví''. O~nepoužitelností takového rozhraní svědčí návody na~tvorbu vlastních dialogů nebo~vývojářský obchod plný pluginů implementujících tento systém lépe.
|
||||
|
||||
\newpage
|
||||
Protože kvalitní řešení jsou~placená a~ty~zdarma jsou~často nevyhovující kvality, byla~navržená vlastní implementace. Jedná~se o~frontu, která~umí přehrávat celé tabulky dialogových vět. Dialog, resp.~množinu vět společného kontextu, lze~pohodlně zapsat do~tabulkového formátu přímo v~editoru. Jednotlivá věta obsahuje id, text, dobu přehrání nebo~zvukovou stopu. Ve~výsledku lze~do~fronty zařadit několik tabulek, které~se~mohou přehrávat sekvenčně od~n-té věty po~poslední, jednu náhodnou větu nebo~přesně jednu větu podle id.
|
||||
@ -188,7 +188,7 @@ Engine disponuje modely základnich tvarů (krychle, koule, valec) a navíc lze
|
||||
V Unreal Engine verze 5 navíc přidali bohatý na funkcionality editor 3D modelů. Tvůrci propagují editor tak, že v něm lze vytvářet vlastní modely, protože množina funkcí dovoluje tvořit ,,hardsurface'' a ,,sculpting'' modely, ale aktuální provedení není dostačujíci a je v nesrovnání s dedikovaným softwarem. Netvořicí ale editovácí funkce na druhou stranu jsou užitečné a šetří čas. Ty umožňují například editování UV map, normalových vektorů ploch nebo změnu středového bodu modelu. ,,Best practice'' je využití tohoto editoru pouze v případě nouze (například časová výhoda nebo neexistence původního souboru) a jinak editovat původní importovaný soubor.
|
||||
|
||||
\paragraph{Použití cizích assetů} Rychlejší a občas jednodušší je získání assetů třetí strany. K tomu existují různé volně dostupné webové platformy. Jednou z takových platforem je FAB, který navíc má přímou integraci s UE 5. Objektivně FAB nemá dostatečně velký výběr assetů, jelikož nemá ani dostatečnou popularitu vývojářů a tvůrců. Přičinou jsou hlavně větší platformní marže z prodeje a sice jednoduchý, ale přesto nevýhodné licencování produktů pro kupující stranu.
|
||||
Z finančních důvodu, v této praci byli využite pouze produkty dostupné zdarma. Neznamená to, že vše skončí pouhým stahnutím souborů a vložením do editoru. Často (v této práci všech 100%) assety nevypovídají žádnou známku optimalizace nebo profesionální tvorby. Modely tak mají některé normaly plošek invertované, středové body jsou nesmyslně mimo, textury a UV mapy je potřeba kompletně předělat. Nejhorší jsou primitivní objekty, které mají bezdůvodně velké množství vrcholů. V praxi se nachází i náhodné vrcholy, bezúčelně rozházené v prostoru modelu.
|
||||
Z finančních důvodu, v této praci byli využite pouze produkty dostupné zdarma. Neznamená to, že vše skončí pouhým stahnutím souborů a vložením do editoru. Často (v této práci všech 100%) assety nevypovídají žádnou známku optimalizace nebo profesionální tvorby. Modely tak mají některé normaly plošek invertované, středové body jsou nesmyslně mimo, textury a UV mapy je potřeba kompletně předělat. Nejhorší jsou primitivní objekty, které mají bezdůvodně velké množství vrcholů. V praxi se nachází i náhodné vrcholy bezúčelně existující v prostoru modelu.
|
||||
|
||||
\paragraph{Vlastní tvorba} Vlastnoručně jsou tvořeny modely ze staré verze hry a během vývoje této práce se pouze upravovali nebo tvořili textury. Standardem v oboru jsou obecně Maya nebo 3ds Max pro všeúčelové zpracování a úpravy, ZBrush pro sculpting a Substance Painter pro texturování objektu. V tomto projektu byl použit výhradně Blender a software pro editaci obrazkových formátů, které jsou k dispozici na internetu zdarma. Výsledný model lze často bez problémů rovnou využít v enginu.
|
||||
|
||||
@ -232,37 +232,98 @@ Unreal engine se jeví standardem herního oboru a proto verze 5 implementuje sy
|
||||
\begin{itemize}
|
||||
\item Instancování -- jíž zmínene v predchozí kapitole -- se využívá k tvorbě prostorů hustých na specifické modely. V UE se jedná o editovácí prostředek sousedicí vedle Landscape. Umožnuje pokročilé nastavení různých množín instancí a jejích parametry náhodného umístění.
|
||||
\item Optimální topologie objektu pro minimalizaci vrcholů potřebných k vykreslování. Převážná většina modelů -- patří sem i získáné od třetích stran -- mají růčně přepracovanou topologii. Jedná se nejen o jednoduchou redukci nepotřebných vrcholů, ale taky použití techniky ,,lítající'' neboli floating geometrie. Tato metoda spočívá v protínání plošek, místo skutečného propojení vrcholů někde uprostřed, protože takové propojení by vyžadovalo podrozdělení jedne z ploch a tedy zbytečného zvětšení vrcholů (viz. \Cref{fig:FloatingGeometry}). Taktéž objekty mají redukovanou k-DOP kolizní topologii, pro urychlení výpočtů fyzických simulací.
|
||||
\item Modely náročné na vykreslování nebo použité v instancování používájí LOD technologii (viz. \Cref{fig:LodShowcase}). Nanite v práci nebyl využit.
|
||||
\item Modely náročné na vykreslování nebo použité v instancování používájí LOD technologii (viz \Cref{fig:LodShowcase}). Nanite v práci nebyl využit.
|
||||
\end{itemize}
|
||||
|
||||
Optimalizace textur je zprovozněná pouze hlídáním rozumných rozlišení. Jinak některé textury určitě je možné seskupit do jedné textury a vybírat potřebnou instanci podle UV mapy, což zrychlí přístup k datům.
|
||||
|
||||
Jiná grafická optimalizace není nijak řešená. Modely použité v instancování občas mohou vyvolat snižení výkonu, což by bylo potřeba už řešit nahrazením plnohodnotných modelů na kolekce průhledných textur.
|
||||
|
||||
\begin{figure}
|
||||
\centering
|
||||
\includegraphics[width=1\linewidth]{img/FloatingGeometry.pdf}
|
||||
\caption{Floating geometrie využitá v modelu okna. Vlevo je výsledný vzhled, uprostřed floating topologie (48 vrcholů a 52 trojúhelniků) a napravo naivní běžná topologie (64 vrcholů a 152 trojúhelniků).}
|
||||
\label{fig:FloatingGeometry}
|
||||
\end{figure}
|
||||
|
||||
\begin{figure}
|
||||
\centering
|
||||
\includegraphics[width=1\linewidth]{img/LodShowcase.pdf}
|
||||
\caption{Ukázka LOD instancí kytky.}
|
||||
\label{fig:LodShowcase}
|
||||
\end{figure}
|
||||
Jiná grafická optimalizace není nijak řešená. Modely použité v instancování občas mohou vyvolat snižení výkonu, což by bylo potřeba už řešit nahrazením plnohodnotných modelů na kolekce průhledných textur (billboard metoda popsaná v další podsekci).
|
||||
|
||||
\subsection{Dynamické a procedurální objekty}
|
||||
%animace baked a matinee / sequencer
|
||||
%trava
|
||||
%modifikace site
|
||||
%optimalizace
|
||||
\paragraph{Sequencer} Dynamická animace se vytváří přímo v editoru objektu Sequencer. Taková animace dokáže modifikovát parametry objektů na úrovní a volát funkce v úrčité okamžiky. Objekty mohou být úrčené předem nebo Sequencer umí dynamicky vyhledát jejích reference před spuštěním. Pravě v tomto prostředí se tvoří cutscény nebo cyklické animace objektů na úrovní.
|
||||
|
||||
\paragraph{Procedurální generování} V předchozí verzi hry modél trávy byl vytvořen pomoci billboard metody, kde místo vykreslování 3D geometrie vegetace, se vykresluje nějaký průník ploch s texturou vegetace a průhledným pozadím. Tato technika je standardem ve video hrach, přesto nestačila k splnění dizajnových účelů. Buď vegetace musela být řídká, nebo stála nesmyslně velkého množství prostředků a tvořili se lag spikes.
|
||||
|
||||
Pro tento účel se implementovál nástroj pro editor, který podle zadaných parametrů je schopný vygenerovát náhodnou a hustou trávu z 3D trojúhelníků. Výsledný objekt má několikanásobně více geometrických dat než billboard metoda, přesto má skvělý výkon a navíc vegetace působí mnohem hustějí, má kvalitnější vzhled a lépe reaguje na offset vrcholů v shaderech (viz \Cref{fig:GrassShowcase}). Trik je v přenesení velké texturové zátěže s převýpočty průhledností na vykreslování jednotné a jednoduché 3D geometrie. K tomu generativní přístup umožňuje kvalitnější pokrytí ploch, jako například v tomto projektu, kde trává se generuje pouze v oblastech určité velikosti a pokryté úrčitým materiálem, tedy tráva se negeneruje na cestíčkach a mezi povolenou a zakázanou plochou je pozvolný přechod v velikosti jednotlivých stebel. Takový přístup byl okoukan ze hry Ghosts of Tsushima od studia Sucker Punch Productions, kde autoři si vytvořili podobný proprietární nástroj, jelikož chtěli dosáhnout husté kinematografické a stilistické vegetace na konzolích.
|
||||
|
||||
\begin{figure}
|
||||
\centering
|
||||
\includegraphics[width=1\linewidth]{img/GrassShowcase.pdf}
|
||||
\caption{Ukázka procedurální (vlevo) a billboard (vpravo) metod pro vykreslování vegetace. Procedurální metoda má přibližně 6-krát menší render time a paměťové požadavky.}
|
||||
\label{fig:GrassShowcase}
|
||||
\end{figure}
|
||||
|
||||
\subsection{Osvětlení}
|
||||
Nabízí se nám dostatečné možností při výběru druhů osvětlení. Teměř každý z ních sdíli podobné parametry, které mohou definovat, to jak světlo vypada nebo ovlivňuje prostředí. Vedle běžných dizajnových parametrů nechybí ani široká škála technických triků a úskalí.
|
||||
|
||||
\paragraph{Forward shading} Jelikož celá hra je ve forward shading režimu, -- podle tvůrců enginu obsolete funkcionalita čekájící na plný rework, -- některé technologie jsou značně omezeny nebo nefungují a zhoršuje se to s každou novou verzi. Například proto není použitelný Rect Light, ale můžeme to obejít tak, že Point Light zdroji přiřadíme IES Texturu, která nám specifikuje tvar světla. Stejně tak lze vytvořit vlastní Light Function, což je materiál definujicí co a jak světelný zdroj vyzařuje.
|
||||
|
||||
Navíc je potřeba pamatovat na reálná technická omezení forward shadingu, jako nejvýše tři zdroje světla na jeden objekt a nedostatek SSAO nebo SSR. S čímž stále si můžeme nějak poradit. Pokud je potřeba víc zdrojů světel ve scéně, máme k dispozici tři různé sloučitelné kanály, které můžeme specifikovat pro konkretní objekt a zdroj světla. A pokud nutně potřebujeme Ambient Occlusion mužeme použít Lightmass Volume pro jeho simulaci a stejně tak můžeme použít Planar Reflections pro simulaci odrazů.
|
||||
|
||||
\paragraph{Základy osvětlení na úrovni} Kromě bodových světel na úrovní teměř vždy chceme přidat globální osvětlení, který sestává z Directional Light a Sky Light.
|
||||
|
||||
Directional zdroj funguje jako jeden velký bodový zdroj pro celou scénu, který napodobuje funkci slunce a slouží primárně k vykreslování stínů.
|
||||
|
||||
Zdroj typu Sky Light taky může ovlivňovat stíny, ale primárně zobrazuje Sky Box texturu a modifikuje ambient složku celého osvětlení.
|
||||
|
||||
Navíc pokud chceme zobrazit venkovní prostory, je dobré použit nějkou formu mlhy jako je Ambient Fog. Mlha přidá pocit vělkého a neomezeného prostoru ikdyž ve skutečnosti je malý a uzavřený. Navíc mlha výborně skryje a tedy umožní horší detalizaci objektů v dálce, čímž efektivně zkratíme renderovácí čas snímku.
|
||||
|
||||
Nakonec se lze uchýlit k použítí Volume objektů, kterých je velké množství a z důvodů rozsahu práce nebudou podrobně probírany. Pomoci těchto prostorů lze specifikovat oblastí s úrčitými parametry, které nějak budou napovídat enginu potřebné optimalizace, nebo zapínat výkonostně náročné vykreslovácí technologie. Pro představu Lightmass Importance Volume specifikuje oblast, kde je potřeba propočítat větší počet odrazů paprsku světla než jednou.
|
||||
|
||||
\subsection{Post-Processing}
|
||||
Post-Processing lze definovat přímo v kameře nebo v jíž zmíněných Volume objektech. Každá definice je de-facto materíál, který lze vrstvít mezi sebou. PP vyžaduje hlubší grafické znalosti, aby bylo možné vytvořit něco užitečnějšího než barevnou korekci. Zároveň kvůli tématice práce jen nastínim jak jsem naimplementoval PP materiály (viz \Cref{fig:PPShowcase}), které mají gamedizajnový důvod, ale nestíhly se použít.
|
||||
|
||||
\begin{figure}
|
||||
\centering
|
||||
\includegraphics[width=1\linewidth]{img/PPShowcase.pdf}
|
||||
\caption{Ukázka post-process materiálů ve hře. Efekt deště jsem nedokázal rozumně zachytít.}
|
||||
\label{fig:PPShowcase}
|
||||
\end{figure}
|
||||
|
||||
\begin{itemize}
|
||||
\item Plovoucí obrazovka - UV prostor obrazu se lehce zakřiví pomoci animováné šumové textury.
|
||||
\item Námraza - obraz interpolujeme s animavánou texturou. Nejlépe použít nejký gradient uprostřed jako pmasku průhlednosti, aby hráč měl čistší vídění.
|
||||
\item Stylová dálková kamera - obraz rozložíme na trochu sesunuté proužky dle rozlišení výstupu a zároveň stejné proužky střídavě zabarvíme. Nakonec proužky animujeme posunem nahoru resp. dolu.
|
||||
\item Dešť - obraz rozložíme na jemnou mřížku a v blocích vygenerujeme různé kapky pomoci složení dvou turbulencí, každá z kterých bude mít animovanou lehce odlišnou rychlost posunu (aby kapky nebyly stalé stejné). K tomu znovu rozložíme obraz, ale teď na hrubou mřížku, kde animujeme svislé pády bloků s gradientním ocasem. Oba výstupy složíme, tak že hruba mřížka bude animováná maska průhlednosti, která name bude v nějaký okamžik otevírat pouze nějaké kapky. Nakonec přidame trochu distortion a výsledek použijeme jako modifikator UV výstupního obrazu.
|
||||
\item Pixelizace - rozložíme obraz na potřebnou mřížku dle rozlišení a modifikujeme UV prostor výstupního obrazu.
|
||||
\item Tavení pixelů - vytvoříme netriviální vertikální gradient s více přechody. Výsledek znečistíme přimím zaokrouhlováním a umozňováním dat, zpixelizujeme rozdělením na mřízku a výsledek použijeme k modifikaci UV prostoru výstupního obrazu a barevné korekci.
|
||||
\item Slepota - výstupní obraz nahradíme vlastním, ve kterém zobrazuje pouze ohraníčení objektůs effektem emise. Ohraničení lze dosáhnout různymi způsoby a v tomto projektu je implementováné pomoci drobného posunu hloubkouvé textury ve všech směrech. Mezi posuny se provede rozdíl s originální hloubkou a sloučením rozdílu dostaneme hrany objektů.
|
||||
\item Tužka a papíř - výstupní obraz nahradíme texturou ambient occlusion.
|
||||
\end{itemize}
|
||||
|
||||
\subsection{Osvětlení, efekty, Post-Processing}
|
||||
\subsection{Materiály a shadery}
|
||||
Prestože materiály jsou omezené shadery, stále lze pomoci nich definovat mnoho různých a komplexních grafických funkcí. Základem jsou jednoduché barevné výstupy s triviálními parametry lesku, matnosti a emise. Může záležet na druhu objektu, pro který materiály tvoříme a tedy potřebujeme správně nastavit i druh materiálu, čimž následně dostaneme další předtím uzavřene výstupy a vstupu nebo některé naopka definovat nebudeme moct. Například za účelem optimaizace, můžeme přepnout material ze základního režimu osvětlení neboli Default Lit do neosvětleného režimu Unlit, čimž budeme moct definovat barvu objektu pouze emisní složkou, ale zmenšíme vykreslovací čas potřebný pro materiál.
|
||||
|
||||
V UE materiály resp. shadery mají mnoho globálních proměnných z kterých můžeme získat cenné údaje o enginu, scéně, vykreslovaném objektu, render buffrech a atd. Dokonce můžeme definovat vlastní globální nebo lokalní parametry a měnit jejich hodnoty v logice světa. Použití takových proměnných lze často vidět právě již zmíněných post-procesech, které přebírají a modifikují hodnoty výstupního zobrazení nebo jsou animaváné pomoci sinusové funkce s globálním parametrem herního času jako vstup.
|
||||
|
||||
Stojí za to zmínit, že některé materiály se hodí pouze na úrčitý druh objektů podle velikostí a umístění ve světě. Jedním z příkladu v teto hře je materiál skla. Původně navržený shader, který simuluje zalomování a vnitřní objem, skvěle funguje na drobných objektech jako lahve nebo skleněné střepy. Při použití na velkých skleněných plochach jako jsou okna, takové simulace vytváři nežádané artefakty nebo nefungují správně. Pro takové situace byl přidan duplicitní shader skla, který primarně vykresluje polopruhlednou barvu na povrchu objektu.
|
||||
|
||||
\paragraph{Funkce} V materiálech se lze zbavit duplicitního kódu, čímž zaroveň se zrychlí kompilace a běh shader variací. Implementoval jsem funkce:
|
||||
\begin{itemize}
|
||||
\item Škalování vstupné hodnoty podle vzdaleností od kamery.
|
||||
\item Uniformní škalování a tiling textury nezávislé na velikosti objektu.
|
||||
\item Získání obrysů objektů v podobě masky.
|
||||
\item Rotace objektu ve směru kamery.
|
||||
\end{itemize}
|
||||
|
||||
\subsection{UI}
|
||||
\subsection{Načítací obrazovka}
|
||||
\subsection{Textové překlady}
|
||||
Před Unreal Engine 5 teměř každý UI byl rastrový a v minulosti to ani nebyl problém. Stačilo vytvořit mip-mapy pro pár nejrozšířenějších rozlišení (HD, WSXGA a Full HD) a k tomu škálovat mip texturu menšího rozlišení na potřebný lehce větší výstup. Předtím hry nevypadaly zaostřeně takže nemuselo ani UI a dokonce to rozostření rastrového obrazu nebylo tak viditelné na displejích menší velikosti v té době. Dnes rastrové UI vytvaří příliš komplikací při tvorbě a vykreslování. Je potřeba mnoho mip-map ve velkých rozlišeních pro ostrý obraz na každém displeji, což vyžadují velké množství paměti a hlavně velkou propustnost při čtení dat (hlavně animací).
|
||||
|
||||
Jelikož původní projekt vznikal ve čtvrté verzi enginu, ale v době již velkých rozlišení, nebylo realistické pro dva vývojaře celé hry vypracovat přijatelné rastrové UI. Proto jsem tehdy a teď vytvořil všechny prvky pomoci černobílých poloprůhledných vektorových čtverců s transformacemi. Rastrové textury se používají pouze v podobě masek nebo gradientů, při použití kterých nejsou zřejmé škalovací artefakty.
|
||||
|
||||
Všechny kořenové UI prvky (overlay prvky, kontejner questů, kontejner nápověd ovládání, menu atd.) spravuje mnou implementováná třída Widget Manager. Táto třída slouží nejen jako high-level api pro všechny kořenové prvky resp. kontejnery, ale primárně slouží pro přehlednou udržbu referencí na takové prvky. Bez manuálního udržování reference, po instancování libovolného UI prvku, ji již nelze získat. Tedy nemuže prvek ani odstranit z obrazovky.
|
||||
|
||||
Každý prvek se instancijuje na začátku a udržuje se v paměti po celou dobu. Hlávním důvodem je naplňovaní prvků daty, které občas může trvát déle a tedy při dynamickém instancování vyvolavat zaseknutí aplikace.
|
||||
|
||||
\paragraph{Texty a překlady} V enginu je více druhů řetězců:
|
||||
\begin{itemize}
|
||||
\item FString - běžný řetězec pro reprezentaci UTF-16 se stejnou množinou funkcí jak u std::string. Je optimalizovaný pro konkatanace - 8 bajty.
|
||||
\item FName - pouhý ukazatel na tabulku triviálních unikatních bajtových řetězců. Používa se pro pojmenování konstant v kódu nebo tagování objektů a je to doporučený textový format pro přenos přes internet.
|
||||
\item FText - komplexní řetězec schopný překladat obsah podle tabulky nebo formatovat čísla podle pravidel jazyka.
|
||||
\end{itemize}
|
||||
Engine při instancování úrčitého FText nebo FString se snaží najít již existující instanci v paměti čimž se dost redukuje duplicita dat zejména v blueprintech.
|
||||
|
||||
Při tvorbě projektu jsem si dál záležet, aby veškerý text viditelný hračem byl překladatelný. Zároveň jsem dbal na zachování unikátností řetězců, aby se v tabulce překladů nevyskytovali duplicitní záznamy.
|
||||
|
||||
\section{Audio}
|
||||
\label{sec:audio}
|
||||
@ -289,6 +350,7 @@ V budoucnu by také pomohlo zabalit všechny hlasy a jiné audio do samostatnýc
|
||||
\section{Tipy při vývoji v UE}
|
||||
\label{sec:UETips}
|
||||
|
||||
\paragraph{Načítací obrazovka}
|
||||
\paragraph{Skripty pro editor}
|
||||
% Blueprunty a python
|
||||
\paragraph{C++ typy a reflexe}
|
||||
|
BIN
img/GrassShowcase.pdf
Normal file
BIN
img/GrassShowcase.pdf
Normal file
Binary file not shown.
BIN
img/PPShowcase.pdf
Normal file
BIN
img/PPShowcase.pdf
Normal file
Binary file not shown.
Loading…
Reference in New Issue
Block a user