Mesh vom SinglesurfaceEntity entfernen
Übersicht

![]() |
rctunerBetreff: Mesh vom SinglesurfaceEntity entfernen |
![]() Antworten mit Zitat ![]() |
---|---|---|
hallo,
ich bin auf die folgende Funktion gestoßen: Code: [AUSKLAPPEN] Function AddToSurface(mesh, surf,singlesurfaceentity)
Local vert[2] For s = 1 To CountSurfaces(mesh) surface = GetSurface(mesh,s) For i = 0 To CountTriangles(surface)-1 For i2 = 0 To 2 oldvert = TriangleVertex(surface,i,i2) TFormPoint VertexX(surface,oldvert),VertexY(surface,oldvert),VertexZ(surface,oldvert), mesh,singlesurfaceentity vert[i2] = AddVertex(surf,TFormedX(),TFormedY(),TFormedZ(),VertexU(surface,oldvert),VertexV(surface,oldvert)) Next AddTriangle(surf, vert[0], vert[1], vert[2]) Next Next End Function So nun meine Frage: Gibt es auch eine Möglichkeit ein Mesh welches vorher mit AddToSurface() hinzugefügt wurde, wieder zu entfernen? Sowas wie DeleteFromSurface? Dazu müsste ich aber die Position des hinzugefügten Meshs kennen, da ich das Mesh erst entfernen möchte wenn die Entfernung zur Kamera zu groß ist. Ist das Möglich? |
||
[Y[our Film, Game ]M[akers and more [F]un!
www.Master-Entertainment.de.vu [AMD 6000+ X2 @ 6400+][2GB RAM][NVidia 8800GT 512 MB] |
Dreamora |
![]() Antworten mit Zitat ![]() |
|
---|---|---|
ja das ist sogar relativ einfach, gleich wie in 2D mit zeichnen:
clearsurface und den rest wieder einfügen. |
||
Ihr findet die aktuellen Projekte unter Gayasoft und könnt mich unter @gayasoft auf Twitter erreichen. |
![]() |
rctuner |
![]() Antworten mit Zitat ![]() |
---|---|---|
danke so hab ich das auch versucht. Nur leider absolut nicht realtime fähig bei vielen objekten.
gibt es denn keine möglichkeit einzellne Vertex zu löschen? |
||
[Y[our Film, Game ]M[akers and more [F]un!
www.Master-Entertainment.de.vu [AMD 6000+ X2 @ 6400+][2GB RAM][NVidia 8800GT 512 MB] |
Dreamora |
![]() Antworten mit Zitat ![]() |
|
---|---|---|
nö und würde auch keinen unterschied machen denn das mesh muss komplett wieder zur grafikkarte hochgeschickt werden.
und das geht aus prinzip nicht in echtzeit, kostet sehr viel bandbreite. Das ist der grund warum man für sowas heutzutage shader nutzt so das es nimmer versandt werden muss sondern direkt auf der GPU gemacht werden kann. aber man kann das ganze optimieren indem man es nicht sinnfrei übertreibt: 1. nicht die ganze zeit sondern nur wenns wirklich nötig is neu aufbauen 2. nie 20'000 polygone und so spässe in eine einzelne surface dabei sollte ich erwähnen das selbst auf meiner 7600go (7300 desktop) 33000 polygone durchaus echtzeit fähig sind. auch wenns hinrissig ist das so brutal durchzupumpen (habs nur zu benchmarking zwecken gemacht für ein dynamisches terrain system) |
||
Ihr findet die aktuellen Projekte unter Gayasoft und könnt mich unter @gayasoft auf Twitter erreichen. |
![]() |
rctuner |
![]() Antworten mit Zitat ![]() |
---|---|---|
k danke für die antwort. Vielleicht hast du ja eine bessere Methode für mein Problem.
Das ganze sollte für ein Baum-LOD-System genuzt werden. Ab einer bestimmten entfernung sollten die Baum Meshes dann durch Sprites in einem Singlesurface System ersetzt werden. Doch leider läuft das auch sehr schlecht bei vielen Bäumen. Wie wird das bei SpeedTree gemacht? Soweit ich weiß werden dort auch Sprites ab weiter entfernung benutzt. |
||
[Y[our Film, Game ]M[akers and more [F]un!
www.Master-Entertainment.de.vu [AMD 6000+ X2 @ 6400+][2GB RAM][NVidia 8800GT 512 MB] |
Dreamora |
![]() Antworten mit Zitat ![]() |
|
---|---|---|
Speed Tree kannst du nicht klonen mit Blitz3D.
1. DX9 ist bedeutend besser für massive "geometriepusherei" ausgelegt (hat optimiere treiber, DX7 treiber sind trash) 2. Speed Tree nutzt shader 3. Es hat nen Grund warum ne Speed Tree Lizenz 100'000 USD kostet ![]() aber selbst das hilft net, in LOTRO zb hat man massive popups auf den niedrigeren einstellungen und dennoch zieht speed tree massiv an der performance. Was du machen kannst (und musst) ist bäume in baumgruppen / sektoren unterteilen und dann innerhalb des sektors anpassen. das ist aus mehreren gründen gut: 1. kleinere surfaces zum rekonstruieren 2. Du kannst mit näherungen bei den berechnungen die distanzberechnungen stark reduzieren eine andere möglichkeit, und eine die vermutlich bedeutend einfacher geht, ist effektiv mit multi LoD Meshes zu arbeiten und distanzabhängig eine andere Lod Stufe zu nutzen. das erreichst du indem du die verschiedenen lod stufen des baumes direkt im model hast das du lädst, jeweils als child und via hide entity und show entity arbeitest und die bäume via copyentity erzeugst. aber die dinge alleine werden dir nix bringen. Denn du wirst immer noch massiv viele unnütze berechnungen machen. Ohne Portalling und ähnliche algorithmische Dinge wirst du nicht einmal im ansatz in die nähe davon kommen, da investierst du lieber in Gothasofts TreeParty / GrassParty |
||
Ihr findet die aktuellen Projekte unter Gayasoft und könnt mich unter @gayasoft auf Twitter erreichen. |
![]() |
Mr.Keks |
![]() Antworten mit Zitat ![]() |
---|---|---|
ich sehe das echt nicht so düster wie dreamora.
1. es tut keinem weh, wenn du die lodstufen nur alle paar frames aktualsierst. 2. wenn du ein baum-sprite löschen willst, kannst du es auch einfach deutlich unter die erde verschieben und dann nur alle paar sekunden mal ordentlich aufräumen. falls dir das neuerstellen zu lange dauert, kannst du das ja sogar über mehrere frames dehnen und das mesh mit dem neuen fertigen surface erst zeigen, sobald es soweit ist (quasi doublebuffering auf einem surface verwenden). |
||
MrKeks.net |
Dreamora |
![]() Antworten mit Zitat ![]() |
|
---|---|---|
Erinnert an BlitzGrass Methode fürs spawning mit dem growing grass ...
Ich sehs auch nicht düster, aber für effizient ist portalling unerlässlich wenn man auch nur ansatzmässig ne Vegetationsdichte mit büschen und bäumen erreichen will, weil wenn man 360 grad aktualisieren muss statt nur <= 180 grad hat das einen erheblichen einfluss. |
||
Ihr findet die aktuellen Projekte unter Gayasoft und könnt mich unter @gayasoft auf Twitter erreichen. |
Übersicht


Powered by phpBB © 2001 - 2006, phpBB Group