MeshEmitter.v4p (31.5 KB)
Hallo, here an example patch where I switch between an image from assets and a dynamic texture (same issue from a Temp Renderer), the Geometry buffer is somehow messing up the geometry, not sure how to debug it, any hint? Thanks
Geometry comes with UV mapped textures, you provide an unmapped texture.
Could that be the problem?
The UV mapping is part of the Geometry, so changing the texture input should not affect it (?).
Hi. That’s because Liquish gives texture with 0 on alpha
As i remember there was a test somewhere to emit only if alpha > 0
Hallo, yes thank you that was it. Let me show you another example where I am having some issues, using it with Noodles mesh modifier, Tesselator for example.
MeshEmitter-Geometry_issue.v4p (27.2 KB)
Well Geometry Emitter was more a proof of concept, then a ready to go solution, because you cannot know witch channels geometry would have you have to build up template for people to extend or huge if switch witch tries to cover as much cases as possible resulting unreadable code…
So, the red circle is what you have, and the yellow circle is what it is expects to get:
First you have to decide what you want more, write an converter that would conver from instance noodles to particles geometry emiiter, or write an geometry emitter that would take instance noodles geometry (on my taste second is way to go, to do so:
-
You have take layout that Tesselator outputs and use it as an input on the GeometryBuffer
-
You have to fix layout in patch…
and that should work
to start doing so you copy GeometryBuffer(bla-bla).v4p and GeometryBuffer_PassInstanced.fx to separate folder, then you rename both of them, fix naming and then fix code…
1 Like
Hallo thank you for the steps, I got the main idea but really could not make it work that way, there is maybe a question I would like to ask:
- in your last screenshot why you say I should change the output layout? That is what the emitter wants: position, normal and color, to draw the particles so that should stay the way it is (?)
Anyway I think I have pinpointed another issue:
it seems to me that PerVertexDrawer/Topology/Instancer cannot get the proper vertex count maybe for the way Noodles sets the IID within the GeometryBuffer. If I bypass the instancing nodes I can get it working, that is only for a single object obviously.
GeometryBufferedNoodles.zip (15.2 KB)
Ah yea, you are right…
PerVertexDrawer/Topology/Instancer
PerVertexDrawer tries to draw points only once instead of repeating them
Topology - set’s to point list, so you can write points to buffer (e.g. not triangle point)
Instancer - applies SV_InstanceID semantics to geometry…
As for instancing in noodles i think it’s done bit different then regular one, basically after each streamout you would loose instancing info, that’s why you have this IID, to keep Instance ID with geometry, so if you want that to work, you have to take it from buffer…
Technically speaking, the streamout and streamout renderer takes everything and writes to one plane buffer (like a spectral node) so if you had some fancy stuff like PerVertexDrawer/Topology/Instancer you would have just a huge buffer of data after that, so basically buffer would keep all the instances compiled and merged geometry and not the data about how instances was created (if that makes sense to you) so in this case i guess PerVertexDrawer and Topology would make sense, however i’m not sure if they do their job with StreamOut geometry… I’m pretty sure you can provide layout during streamout stage…
To be honest i would use ByteAddressBuffer in this case…
This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.