VertexBuffer (split) seems b.o.r.k. again!?

Hey guys,
since Text (EX9) Mesh split bug [solved] is /not related/, i gotta open a new one…

So i’m still running a project that has important setup media stored in the .x format
i need this to work. However, using |VertexBuffer (EX9.Geometry.split)| messes up the numbers of the XML file totally. Position, TexCoords, everything is messed in a strange way (see also VertexBuffer(Split)_ruins_Xfiles.v4p (17.9 KB)
for example with Key_00.7z (1.2 KB)
. Might have to replace camera with [Camera (Blender)])

This is an ALERT. I have several Tschunks[1] at work and Easterhegg 2018 is progressing, oktoskop not performing… If you are awake, please please help me hunt that bug down. I will pay in Tschunk.

[1] Tschunk: Ice, Rum, Mate.

A minor workaround. If this helps: I want the Tschunks shaken, not stirred ;)

VertexBuffer(Split)_workaround.v4p (16.8 KB)


Unfortunately, i’m loosing the second UV.Layout which is crucial for the mapping :(
Is there a quick fix to access that?

Tschunk anyway for solving the original problem. I had never realized that [Scene File] can read .x files.

You acess that in vertex shader by specifing uv1: TEXCOORD1 in VS_IN

Don’t think an x-file supports multi texturecoords

I use collada for that

If you still have trouble post model, simplified patch and shader…

@blausand you’re saying (in the patch) the output of your patch looks different in b35 as compared to b36? i cannot reproduce this. can you please show two screenshots of how they look different?

Thanks for any quick responses guys. Easterhegg 2018 was great and “Rabbits & Byterflies” have amazed people; everybody loved the special glitch effect that came from messed UVs :))
@antokhio, “specifing uv1: TEXCOORD1 in VS_IN” is exactly what i am doing in my shader. But before, i employ [Vertex Buffer (split)] to get numbers for the [Point Editor] and [Vertex Buffer (join)] for resemble the mesh which is then saved to disk. The same happens once more using a UV Editor Tool for the UV1.
@joreg, by now i installed b35 in Windows 10 and the problem persists.
That means: It’s either

  • the shift from Windows 7 to 10 itself or
  • the shift from NVIDIA GTX 970 to 1070 or
  • the corresponding shift in graphic drivers’ version.

I’ll happily add some screenshots as soon as i find the time; pretty sure some of the guts of oktoskop could be refactored anyway; it’s just two other major projects that rip my attention from -erm- right now…

EDIT: Ok, so i edited the example to show some of the glithces at once:

Additional comments about the attached Screenshot:

  • I replaced the generator node [Grid] by a readback of the saved .x file. Now we see the fucked up numbers in the Inspektor as well as the coordinates in the live Renderer.
  • Going Fullscreen with the DX9 Renderer on the second screen in FullHD fucks up the NVIDIA driver completely. I have to deactivate the device and activate it again, and restart vvvv. This only happens if i choose resolution “1920x1080” or “AsDesktop”. DX11 is also fine.
  • The DX11 version fucks up the UV-coords of the very same file, as you can see on the right.
  • The [Vertexbuffer (Join)] seems to do different things when you feed a single standard normal vector instead of a spread. From my experience in the Point Editor, it seems to fail joining vertices, resulting in a much higher vertex count (red mark in bottom left text editor tab).

I issually store second texture channel as txt and upload to gpu as dynamic buffer…

Meanwhile there are some differences for splitting meshes in dx9 and dx11 if you upload your example i can try to make it work

Short words, when you upload ur mesh to gpu, you do this by specifying vertex and index buffer, so when gpu processed mesh it’s already a list of triangles without indices, that’s why you have more triangles then you start with, and mesh also differnt from the one you start with, prolly you have an error somewhere there, what you export what you had and what you get… driver crash is because you upload to gpu something it can’t handale…

This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.