MeshTriangle

[Kjell]

A MeshTriangle Component would be convenient.

K

[jph_wacheski]

I'll second that,.

Perhaps also a renderLine (glLine) componet for cross-platformed-ness,.

[VilleK]

How should it be designed? Something like this?

MeshTriangle is a mesh producer that generates a single triangle.
Use it in a loop with MeshCombine to generate a mesh one triangle at a time.
Properties: V1,V2,V3 represents each vertex.

Please give a practical example when it would be useful.

[Kjell]

Well,

Even more convenient would be a mode dropdown ( Points, Lines, LineStrip, LineLoop, Triangles, TriangleStrip, TriangleFan, Quads, QuadStrip, Polygon ) on the Mesh component, in combination with a MeshVertex Component. Then you can do everything .. point-clouds, outlines etc.

Anyway, a MeshTriangle component is for example useful for terrains .. right now you need to add individual BoxMesh ( 2D ) Components in a loop and rotate them depending on how you want the "Quad" to be split. Another obvious use is importing during runtime

Properties for the Texture Coordinates and Normals of each vertex would be handy too ( otherwise you still need to use a MeshExpression with multiple if-statements ).

K

[VilleK]

The problem is that ZGEs internal mesh-format is limited to triangles. We could make it a render-component instead:

RenderVertexPrimitive Type=Lines/Points/Quads
--Children
----Repeat
------VertexEntry V,TexCoord,Color,Normal

[Kjell]

The problem is that ZGEs internal mesh-format is limited to triangles.

Yea I know, that's why I requested MeshTriangle .. since that's probably allot less work.

Wouldn't there be a significant performance difference between a "scripted" loop ( reading / assigning all values from a Array ) and using the Mesh component? And VBO's will probably not be possible that way either, right?

K

[VilleK]

The performance would be similar to that of the MeshNet component. So it would not be suitable for a rendering a large terrain but it could still be useful for effects. Still, the benefit of doing this with a component compared to using Opengl-external library is questionable imo because it is quite straightforward to achieve with normal scripting + external library.

[Kjell]

Yea,

That's the reason for this request to begin with. Right now I'm rendering all my meshes that require exposed vertex index or triangle level updates using opengl32 .. which gives significantly worse performance compared to using the Mesh component.

K

[VilleK]

The question is which is faster for rendering mesh that requires vertex updates each frame:
1. rendering with external opengl-calls
2. regenerate the mesh using RefreshContent and render using RenderMesh

Even though the second method can use VBO:s I wonder if the additional time of regenerating the mesh won't give a total time similar to method 1? At least if you are only rendering a single instance of each geometry.

Of course there is also the additional possibility of using geometry shaders. Maybe I should investigate that again instead?

[Kjell]

I'm only updating / creating the meshes once, after that they remain static.

K

[jph_wacheski]

One reason I would like to see MeshTriangle, Line, and such in components rather than DLL calls is for OSX,. as those will not work, right?

Perhaps a Model AND a Render component would make sence,. as I can see uses for each, Render for animation stuff,. and the other for static model constructions,.. .

[Kjell]

Code: Select all

function Platform_LoadModule(const Name : PAnsiChar) : integer;
begin
  //TODO: module support
  {$if Defined(Linux) or Defined(Darwin)}
  Result := Integer(dlopen( Name, RTLD_NOW));
  {$else}
  Result := 0;
  {$endif}
end;

function Platform_GetModuleProc(Module : integer; const Name : PAnsiChar) : pointer;
begin
  //TODO: module support
  {$if Defined(Linux) or Defined(Darwin)}
  Result := dlsym(Pointer(Module), Name );
  {$else}
  Result := 0;
  {$endif}
end;

Both Mesh AND Render components doesn't make sense imo. You end up with duplicate functionality like we have now with the Mesh+MeshBox(2D)+RefreshContent+RenderMesh and RenderNet.

K

[VilleK]

Dll/module-calls work for OSX (this is the "Darwin"-define) however there are strange problems with calling OpenGL. Rendering points or lines with glBegin/glEnd works for less than 10 or so vertices, then it crashes. On Linux it works perfectly.