Welcome to Code Forum!

Join a community that supports you and your coding journey from day one. We strive to be a friendly, supportive community that empowers everyone to be better developers. By registering with us, you'll be able to discuss, share and private message with other members of our community.

SignUp Now!

Fast GPU whole shapes sort, best way?

JosiahMaybe

Platinum Coder
All I know at this point is trying to to do like whole shapes sort as opposed to per pixel sort, may require cutting shapes that intersect planes or that intersect edges in 2d view plane, for draw order only things that are in same space relate or need any specific order, I could randomly merged otherwise. It will be using Slang shaders and parallelism. This all would be for an any dimensional algorithm but it simplifies to like a 3d. I prefer not to store new points because 3 to 3000 dimensional could be.

I am trying to meet or exceed A-buffer stuff, this kind perfectly handles alpha/opacity/whatever you call it, I already know what I would do and all those seem to fail to be as fast. Ideas? I honestly think this should be faster simply because much less work than per pixel. It would be z based and compared at corresponding points, use edges for a maximum of 5 z things made or considered. Cut lines can be 2 integers and a float for where a long original. It will be only planar polygons, lines, and points. X E.
 
Probably easiest part of this to solve is fastest 2d group by intersections and same spaces, I have been researching this, what is recommended? Basically cut to no edge intersects and no plane intersects, AI is just loopy on this, not O(N) probably as suggested by grok on X. There are no other cuts. There are no more opacity needs as whole shapes are correctly ordered. Clustering seems fast and so does sweep line. X E.
 
Your approach is theoretically sound and could outperform A-buffers for many cases. The key is minimizing cutting overhead and maximizing parallelism. If you can efficiently reject non-overlapping shapes early, this should fly...
 
Also, a good note, I have a good cutting and in or out algorithm. If an edge intersects then cuts needed, if none, then check if a single point of one is in another and opposite, use axis aligned bounding boxes to tell, I have like find maybe on an axis two closest points on either side, if no two sides then outside, then use angles for which way is inside. It is 100% accurate. Also, I can randomly sort or not even sort not overlapping stuff. X E.
 
Last edited:
I should mention, like my in or out algorithm requires which rotational direction is in for going one way in indices, I guess I can go by a min or max point in any 2d dimension and more in that way that is known as out, and find which side it is on from going one way around. That eliminates like my old find area for which way is in, clockwise or counter clockwise. That is like 1 compared and all parallel. I should probably cache bounding box and rotational in. This thing is coming together great. Is it possible to run independent fragment and vertex shader sets? Like draw group 2 while group 1 is drawing. That could be a major optimization too. X E.
 
Back
Top Bottom