Beiträge von Tomura

Jo genau das was der poster aus dem englsichen Forum dir geschrieben hat würd ich auch sagen.

So dinge wie das Offset Vertex painting geht auch ist aber mehr auf shader basis als auf Mesh basis. Am besten wäre in dem fall wenn man dann über Lerp zwei verschiedene Offsets interpolieren würde. Ich glaube aber dass die Morph Target variante zielführender ist und vom workflow her besser da man direkt in 3D arbeitet.

Die Antwort wäre Level-Streaming. Dazu gibt es ein Beispiel in den Content Examples.
Natürlich ist das ganze nicht so einfach. Ein großes Objekt wie ein Planet ist natürlich schon sichtbar bevor das Level in dem er sich befindet sichbar ist. Vielleicht ist er sogar so groß dass er selbst gar nicht in ein Level passt. Also musst du im Weltraum sehr viel herum tricksen und den Planeten z.B. irgendwo in der Skybox rendern, da er gar nicht in dem Level existiert. Am schwierigsten ist dann der Übergang wenn man den Planeten betreten will oder nah dran kommt.

Um ehrlich zu sein wirst du das nicht schaffen, wenn ich den anderen thread von dir sehe. Es fehlt dir einfach an erfahrung dazu und dies ist eine Sache mit der sich sogar ein erfahrenes Entwickler Team schwer tun würde, allein wegen der ressourcen die es braucht eine so große Welt zu erschaffen und zu füllen. Bei einem Open World spiel wie Skyrim z.B. kann man einfach das Level streamen ohne viel Sorgen zu haben, da die sichtweite nicht weit genug ist um die Stellen zu sehen die einfach abgeschnitten sind, dadurch dass es Berge, Wälder, Nebel, etc gibt. Man kann dort nur mehrere Kilometer weit sehen. Im Weltraum ist es ein ganz anderes Monster, da man ja mehrere Lichtjahre weit sehen kann und sehr viele riesige Objekte vorhanden sind, die sichtbar sind, aber definitiv nicht in ihrerer vollen Form geladen werden können.

Du kannst wenn du beim bewegen V gedrückt hältst Vertex Snapping aktivieren. Ich weiß aber nicht mehr ob man dafür irgendeine einstellung oder ein plugin aktivieren muss.
Da mit kannst du aber den Mittelpunkt an einem Vertex der in der Welt liegt snappen lassen, das ist noch nicht ganz das was du willst, wird aber das ganze etwas beschleunigen.

https://wiki.unrealengine.com/…ring_%26_Any_TrueTypeFont

Das Tutorial sollte erklären wie man ein Slate Edit Text Widget benutzt. Im wiki gibt es auch weitere Slate Tutorials falls das hier noch nicht ausreicht um es zu verstehen.

Mal etwas von mir. Ein kleiner run durch meine Test Map in der ich paar Manöver und den flow teste.

So ganz funktioniert das ganze noch nicht im Multiplayer solange Coordinate-Bashing nicht auch Multiplayer fähig wird (sonst gibts ja floating point precision errors). Scheinbar wird aber auch daran gearbeitet.

Zitat von Balmung

Für einige Dinge kann man Photoshop schon gut nutzen, aber bei komplexeren Formen finde ich es auch schöner direkt auf dem Modell malen zu können. Mit Photoshop artet das bei mir schnell in bearbeiten, speichern, in 3D Programm testen und das Ganze wieder von vorne aus... und diese Schritte kosten einfach nur nervige Zeit.

Wenn man mit Photoshop arbeitet hat man meistens sowas wie Marmoset Toolbag parallel dazu offen. Das müsste soweit ich mich errinnere die Texturen automatisch neuladen, wenn man sie in PS gespeichert hat oder per Knopfdruck einfach Refreshen. Wenn man mit NDo und DDo arbeitet hat man dann ja so oder so einen Previewer dabei.

Und jetzt darf der Moderator mal die ganzen Baumdiskussionen hier heraustrennen. Wollte eigentlich nicht das Thema damit in eine andere Richtung lenken sondern nur auf die Technik aufmerksam machen. (Mod sagt: Fertig! :D)

Zum Thema:
Eine andere Lösung wäre die mathematische.
Da könnte man in Blueprint die Funktion Rotate Vector Around Axis nutzen (das spart das manuelle ermitteln einer Rotationsmatrix oder Transformieren in andere - evtl. nicht-karthesische - Koordinatensysteme), um die Subobjekte drehen. Natürlich sollte man dann den Winkel über eine neue Variable steuern und nicht über den Transform.
Das Updaten sollte dann am besten im ConstructionGraph und bei veränderung des Winkels während der Laufzeit übernommen werden.

Du könntest in der Hierarchie ein SceneComponent über dem Mesh mit dem verschobenen Drehpunkt einfügen. Beim Rotieren drehst du dann das SceneComponent, da das Mesh sich in dem RelativSystem befindet wird es dann um den neuen Punkt gedreht.

Nur mal am Rande: Das könnte dir helfen um die Bäume schöner zu machen:
http://wiki.polycount.com/VertexNormal

Die Umsetzung dazu ist sehr einfach in UE4.
Als erstes benötigst du einen SceneCapture2D. Wenn du in den Properties reinschaust wirst du sehen, dass es eine Referenz zu einer RenderTarget brauchst (Texture Target).
Also erstellst du als nächstes im ContentBrowser eine RenderTargetTexture2D. Diese Referenzierst du dann in den Properties deines SceneCaptures.
Nun kannst du diese RenderTargetTexture2D wie eine ganz Normale Texture im MaterialEditor nutzen. Der rest sollte daher klar sein.

Um dann z.B. während der Laufzeit auf dem Bildschirm die Captures wechseln zu können könnte man die Textur im MaterialEditor als Parameter einstellen und dann ein MaterialInstanceDynamic daraus machen, um dann später über Code oder Blueprint den TexturParameter verändern zu können um z.B. auf eine andere RenderTargetTexture2D zu wechseln die einen anderen Kamerawinkel zeigt.

Was zu beachten ist ist, dass dies jedoch sehr viel Performance braucht, da nun mehr als ein Bild gerendert werden muss. Also nicht übertreiben, vorallem mit derAuflösung.

Bei Adobe sehe ich dass PS so 12€ pro Monat kostet, was eigentlich ziemlich erschwinglich ist.
PS ist meiner Meinung nach eine viel wichtigere Invenstition als Substance oder Quixel Tools. Wobei ich selbst auch noch solange es mir möglich war mir die Stundenten Version gekauft habe als es die noch gab und die Lizenz die Nutzung nach dem Studium und auch die kommerzielle Nutzung zugelassen hat. Die scheinen aber jetzt komplett auf das Abo Modell umgestellt zu haben. Für Leute die das Programm Beruflich brauchen ist das ganze aber in so fern von Vorteil dass die Kosten nicht auf einen Schlag kommen, wenn man mal ein Update braucht. Auch für Indies ist es deutlich schöner im Monat die 12€ zu zahlen anstatt um die 700€ auf einen Schlag.

Für Leute die es nicht viel Nutzen ist es natürlich doof.

Da bin ich leider überfragt. Ich glaube aber, dass dir das im Englischen Forum oder Answer Hub von Epic Mitarbeitern oder Community Membern beantwortet werden kann.

Der hauptvorteil ist, dass während der Laufzeit nicht die ganze Zeit im Tick geprüft werden muss ob ein Event eingetreten ist, sondern dies über die Timer Lösen kann, welche als Objekt nur dann existieren während die laufen.
Soweit ich das im Quellcode sehe hat der TimerManager eine eigene Tick Funktion, die einfach alle laufenden Timer durchgeht und schaut ob sie abgelaufen sind und neue Timer in den TimerHeap hinzufügt.
Bei dem Flackern in der Implementation z.B. ist es eigentlich egal ob man einen Timer oder Tick nutzt, wenn es jetzt um den Performancegewinn geht. Vorallem da das was passiert recht einfach ist.

Bei der Waffe zum Beispiel ist es ein Gewinn da die Performance für den Refire Timer, Equip Timer, etc auch nur dann genutzt wird wenn sie nötig ist. Die meisten nicht-kontinuierlichen Sachen profitieren also davon.
Soweit ich einmal im Multi-Threading Tutorial gelesen habe, gab es da einen Comment, dass sich Timer im Main/Game-Thread befinden müssen. Macht auch sinn da es zu Problemen kommt wenn man versucht auf UObjects aus fremden threads zuzugreifen.

NDo und dDo sind großartig. Jedoch ersetzt NDo nicht das baken von Highpoly auf LowPoly, sondern ist eher dazu da um imnachhinein noch details hinzuzufügen ohne dass man das in zBrush oder bei Anorganischen Modellen auch Max/Maya, etc machen muss (was in zBrush wegen der fehlenden 64Bit Unterstützung dann so oder so zum Horror werden kann, da der Arbeitsspeicher schon recht voll wird bei hohen Subdivisions).
Vorallem bei Anorganischen Modellen ist das echt praktisch, weil man dann in Max was High Poly angeht einfach nur Kanten abrundet die Normals baked und dann mit nDo details hinzugügen kann.

dDo hingegen ist ein Segen um sehr schnell Diffuse, Specular, etc zu bekommen. Man braucht vorher nur das die Tangent Space Normals, Object SpaceNormals und AO-Map (letztere kann man sich in nDo generieren) und die Color Map. Beide Tools machen nichts was man nicht manuell machen kann, jedoch schafft man damit Dinge für die man Stunden braucht in paar Minuten, was die Produktivität ziemlich steigert.

Beide Tools sind für mich Must-Have Tools, einfach weil es die Produktivität ziemlich steigert.

damit ist es einfacher zu finden.
Der Hinweis geht noch weiter und sagt dir dann der Fehler in Zeile 11 der *.cpp liegt. Und zwar sind UDirectionalLightComponent und USpotLightComponent nicht kompatibel.

lightComp ist bei dir ein UDirectionalLightComponent, aber du initialisierst es als USpotLightComponent. Was nicht geht.

Beim Blueprint besteht das selbe Problem wie bei deiner C++ Lösung. Wenn du die Zeit drin haben willst wäre es besser bei BeginPlay() einen LoopingTimer zu erstellen der die 0.3 sekunden hat. Das könnte aber ohne zusätzliche Interpolation bei Tick etwas zu abgehackt wirken.

Kannst du den kompletten Output Log posten?

Ansonsten ist aber hier der Timer sinnlos. Da du so oder so in Endeffekt jeden Tick die Funktion Flicker und RandonNumber ausführst, außer in den ersten 0.3 Sekunden. Der Timer ist also nicht notwending und nur resourcen verschwendung.

Mal ein Beispiel fürs loopen:

void ABRSWeapon::TimeWeaponRefire()
{
    GetWorldTimerManager().SetTimer(this, &ABRSWeapon::TryRefire, FireModes[CurrentFireMode].FireInterval, true);
}

Dies ist die funktion die bei MouseDown aufgerufen wird (natürlich nicht direkt und erst nach ziemlich vielen Prüfungen). Diese sorgt dafür, dass eine Waffe immer wieder feuert. Außer der Timer wird gestoppt (wenn die Maustaste losgelassen wird.)
Hier könnte man auch den Timer immer wieder in TryRefire() neu starten. Jedoch würde das bedeuten dass sich dieser Timer erst zerstört nur um dann wieder neu erstellt zu werden. Effizienter ist es daher wie hier in TryRefire einfach den Timer zu stoppen, wenn er nicht mehr gebraucht wird.

void ABRSWeapon::EquipWeapon()
{
   // If Server then notify clients about this. If called on Client or in SinglePlayer SimulateEquip
    if (Role == ROLE_Authority && !(GetWorld()->GetNetMode() == ENetMode::NM_Standalone))
    {
        Multicast_EquipWeapon();
    }
    else
    {
        SimulateEquip();
    }

    WeaponState = EWeaponState::Equipping;
    GetWorldTimerManager().SetTimer(this, &ABRSWeapon::WeaponEquipped, FMath::Max(EquipTime, 0.01f), false);
}


void ABRSWeapon::WeaponEquipped()
{
    GetWorldTimerManager().ClearTimer(this, &ABRSWeapon::WeaponEquipped);
    UE_LOG(LogInventory, Log, TEXT("%s is now active!"), *GetName());
    WeaponState = EWeaponState::Active;


    // if weapon change is pending start it.
    if (bPendingUnequip)
    {
        UnequipWeapon();
        return;
    }


    for (int32 i = 0; i < FireModes.Num(); i++)
    {
        if (IsPendingFire(i))
        {
            FireWeapon(i);
            break;
        }
    }
}

Hier geht es um das Ausrüsten einer Waffe. Der Timer wird diese Mal nur einmal ausgeführt, da nach dem Ausrüsten dieser Timer nicht mehr gebraucht wird.

Die effizienteste Variante ist die folgende:

GetWoldTimerManager.SetTimer(this, &NAMESPACE::FUNCTIONNAME, Zeit, bLooping)

Zeit ist ein float der den Intervall des Timers angibt. Wenn bLooping true ist, wiederholt sich der Timer bis man ihn mit CleatTimer löscht. Bei false wird der Timer nur ein Mal ausgeführt.
&NAMESPACE::FUNCTIONNAME ist der FunctionPointer zu der Funktion die der Timer bei ablauf ausführen soll. Die funktion darf keine Parameter haben und nichts zurückgeben.

Mal als Beispiel ich will im Actor MyActor nach 5 sekunden nach dem aufruf der Funktion "Bla" die Funktion "Blubb" ausführen dann sieht es so aus:

void AMyPawn::Bla()
{
    GetWorldTimerManager().SetTimer(this, &AMyPawn::Blubb, 5.f, false);
}


void AMyPawn::Blubb()
{
    //Diese Funktion wird 5 gameplay sekunden nach Bla() ausgeführt.
    //Tue irgendwas
}

Es handelt sich hier im Gameplay sekunden. Bzw sekunden innerhalb der Klasse in der der Timer läuft. Wenn also der Pawn gerade in slow motion ist, dann läuft auch der Timer langsamer (außer man kompensiert es).

Die über mir beschriebene Tick Variante ist auch in Ordnung, jedoch sind Timer empfehlenswerter, vorallem um zu verhindern, dass unnötig viele Actors ticken müssen.

Mehr dazu hier: https://forums.unrealengine.co…Vs-Tick&p=69839#post69839

Lightmaps befinden sich auf UE4 Modellen auf einem anderen UVW-Channel.
Am besten ist es, wenn du den zweiten Channel selbst erstellst in Cinema4D. Dort sollte es natürlich keine überlagerungen geben.

Zitat von Napelazam

Jetzt schreibt Tomura was ganz anders als phil. Da lese ich, dass BP nur was für Prototypen ist.

Oh das war etwas anders gemeint.
Im letzten Absatz hab ich ja noch geschrieben dass es für kleinere Dinge gut ist. Das mit dem Prototypen war mehr ein Bericht über meine eigene Erfahrung damit.

Der größte Punkt der es entscheiden sollte ist, welcher workflow dir passt. Die Spielelogik ist heutzutage normalerweise nicht der Flaschenhals bei der Performance eines Spieles. Also kann es dir egal sein was du nutzt.
Hohe Performance in der Logik brauchst du vorallem wenn du eine Physik Simulation dazuschreibst oder eine KI die von sehr vielen Einheiten gebraucht wird z.B. bei einem Strategie Spiel, wo hunderte von Einheiten sich Pfade suchen müssen. Solche Aufgaben sollte man natürlich mit der performantesten Lösung bewältigen. Normale Gameplay logik kann meistens ohne große bedenken mit der Performance einer Scriptsprache bewältigt werden.

Zur Zeit läuft es so, dass ich das Grundgerüst in in C++ mache und für die Details Blueprint zulasse. Der erste Grund ist, dass ab einem gewissen Grad komplexität Code einfach viel Übersichtlicher ist als Blueprint. Das Problem hatte ich schon bei Simulink oder LabVIEW. Daher hatte ich schon eine gute Vorstellung wo es sinnvoll für mich ist und wo nicht.
Nehmen wir wieder eine Waffe, so ist in C++ das Grundgerüst geschrieben was die ganze Munitions, Feuer, Ausrüsten, etc Logik übernimmt. In Blueprint müssen dann nur die Defaults angepasst werden und bei bedarf können auch zu den Events (z.B. beim Feuern oder bei einem Treffer, beim Ausrüsten, etc) kleinere Funktionen geschrieben werden.

Nein IE_Pressed heißt dass die Funktion beim Herunterdrücken ausgeführt wird. IE_Released beim Loslassen der Taste.
Im Falle vom Sprinten könnte man z.B. bei IE_Pressed eine Funktion StartRun ausführen und beim Loslassen die Funktion StopRun, um das Rennen zu beenden.

Es gibt auch noch IE_Doubleclick. Für das Doppelte Betätigen einer Taste.

Ja es ist schon deutlich besseres Vorgehen das Framework in C++ zu schreiben und nur sehr spezifische Sachen in Blueprint zu machen.

Sehr gut ist Blueprint natürlich auch zum ganz groben Prototypen. Als ich z.B. mir einen LedgeMarker mit Dynamischer Anzahl an Segmenten erstellen wollte, war es ganz praktisch dass ich zuerst in Blueprint mit einen Actor machen konnte um zu testen ob das Generieren der neuen Segemente und das Updadeten der Kollisionsinformationen richtig funktioniert, und auch die Bedienbarkeit für diesen neuen Actor im Editor austesten und es mit meinem Designer ausdiskutieren.

Ansonsten ist es für kleinere Spezifische Sachen definitv besser, als dass man da eine neue C++ Klasse erstellt die dann nur eine Hand voll funktionen überläd. Z.B. wenn eine Waffe anstelle von Schaden lieber ein Gravitationsfeld spawnen soll, dann ist es deutlich schneller einfach soetwas in Blueprint zu realisieren. Natürlich mit der Annahme, dass die Waffe so programmiert ist dass es geht.