Well, First of all there seems to be a big debate about it. Why? Doubts, or ?
I really don't know how everything is done anyways!
but I program because I like to learn new thing and experiment ect.. I could go on and on but...
There are many ways to skin a cat as the old saying goes.
On another track...
Can someone have a look at this for now?
The model I have is not hi-res but It stores 3d-cloud data into layers and renders it out 2D.
Which still can be I think voxels and not only that but the way I look at it I could maybe do a bit more.
So for now this is a early pre-view of only but a part in what I think is still really hard do.
If anyone can help? I would love optimizations of this because I still see it can support more vertexs if speeded up.
I started a oct-trees program as well and see that the purpose I found can still help in this but load hi-res point cloud data faster I not the great at.
So if anyone can help it would be great. The oct-trees though I seem to see there being used for other things like aka.(sharping-detail).
For me for now they are about rendering voxels quicker. as groups can be expressed instead of always singles.
Still need help here though with more points being pulled in.
Thanks,
Scottie B
Okay, Here's a hi-res version of same thing but it seems like the problem right now is...
The model is taking awhile to load in. for one.
but my sorting algorithm is a heavy load because I don't know how to use playbasics sort array
to also give me the order is which it does sort this information is need because Z-Buffer back to front I need to carry x and y with the z-depth to get it right.
The final volumetric seems good though its not done.
So any sped-ups or opts would be great as I will have more surprizes soon.
Just need a bit more help to make it better.
Anything else noticed would be nice to know while I'm still brainstorming.
Thanks for now.
I'll be back when I can share more or when someone leaves a post or too.
Scott_Bro
https://en.wikipedia.org/wiki/Merge_sort
this can at least help with sorting z buffer into furthest to closest order or other way around. i used this theory (but i modified mine) in my 3D engine and it works fast. only takes several runs of the array.
check out the image half way down the page, this helped me a lot.
good luck with the loading of data, it is slow. i am not familiar with loading big files.
stevmjon
radix sorts / none comparative sorts are good for z buffering
Thanks for the ideas about sorting. I'll have to look into it.
For now I think I need to shorten this program before moving on.
I see where it doesn't need it (sorting) until render time.
Does anyone see my point with using the octtrees for not only increasing detail but...
Rendering groups instead of singles that make a group???
Take a look at this piece of code though it would have to be upgraded.
Identicals are marked and to me this means not only an increasing detail but a (fast way) of rendering. (Voxels) per say but...
Chucks of information of different scales.
Have a look. Any other Ideas are welcome and also It would be nice to hear some input.
It's 2D here but final renders also display 2D back to screen.
Thanks,
Scott_Bro
just looked at the oct tree demo and it is cool the way you presented it. the way it separates detail into smaller quads and darkens the color the smaller it gets.
i have never looked at oct trees before, but i see what you are getting at.
this will help if you are rendering the same color? so instead of rendering individual dots you can render a line/shape which would draw faster?
or are you more looking at sorting the 3D world into chunks (where each chunk has a whole group of points data in it), so the chunk can be checked if valid/seen by camera etc, and if yes then look at group inside chunk?
there's any lot of ways of partitioning space, but if you have a 3d array (a volume) of point data, then it stands to reason that cutting the space into smaller volumes (of say Empty/Solid/Partial->sub sectored) will save lots of space/memory and help with computing what's in view, regardless of the approach.
Imagine the wolf3D demo from the other day, if you flip the problem and forget about the 2D grid / walls and just think about the empty space, you end up with a series of pre-processed linked orthogonal volumes..
Attached:
Attached a pre-computed one I wrote back in DB.. it was turned in a product of sorts about a year later. Visual Worlds (https://www.underwaredesign.com/?page=programs.Visible-Worlds)
this is just an edit for the hi-res demo you posted in reply#1
it runs much faster than the original. easy fixes. just commented out a sync in the load loop, and commented out the i & j loops as they loop way too many times.
i assume you already fixed these in what you are working on, because you mentioned re-doing the z buffer sorting, and the sync in the load file loop i assume was just there so you could see what you were loading...
anyway, thought i would post.
stevmjon
In order to load CSV data the best approach is load the entire file to a string and then split it.
[pbcode]
; PROJECT : Volumetric Rendering_edit
; AUTHOR : Scott
; CREATED : 31/08/2021
; EDITED : 5/09/2021
; ---------------------------------------------------------------------
;; edit by stevmjon to speed up run of program
;; see line 64 : comment out sync command *** dramatically slows down load time
;; see lines 84 - 108 : comment out i loop and j loop *** dramatically slowed down program (too many loops)
X_Screen_Res = 1024
Y_Screen_Res = 768
Color_Mode = 32
Windowed_Mode = 1
OpenScreen X_Screen_Res,Y_Screen_Res,Color_Mode,Windowed_Mode
TitleScreen "Volumetric Rendering Of..."
Number_Of_Points = 35947 //397
Dim Vertex_Data#(3)
Dim X3D#(Number_Of_Points)
Dim Y3D#(Number_Of_Points)
Dim Z3D#(Number_Of_Points)
Scale_Factor = 1000
ReadPOintData("datasets\hi-res\bunny.csv",Number_Of_points,Scale_Factor)
Cls
Scale_Factor = 1000
X_Size = 512
Y_Size = 512
Z_Size = 512
Dim Layers(X_Size,Y_Size,Z_Size)
X_MID = X_SIZE/2
Y_MID = Y_SIZE/2
Z_MID = Z_SIZE/2
For Points = 0 To Number_Of_Points - 1
X1# = X3D#(Points) //0 - X3D#(Points)) * Scale_Factor
Y1# = Y3D#(Points) //(0 - Y3D#(Points)) * Scale_Factor
Z1# = Z3D#(Points) //(0 - Z3D#(Points)) * Scale_Factor
X = X_MID + Int(X1#)
Y = Y_MID + Int(Y1#)
Z = Z_MID + Int(Z1#)
Layers(X,Y,Z) = 1
Next Points
Print "Ready!"
Sync
//LockBuffer
//Seed = Point(0,0)
X_ScreenMID = X_Screen_Res / 2
Y_ScreenMID = Y_Screen_Res / 2
For Z = 0 To Z_Size - 1
For Y = 0 To Y_Size - 1
Ypos = (Y - Y_MID) + Y_ScreenMID
For X = 0 To X_Size - 1
If Layers(X,Y,Z) > 0
Dot (X - X_MID) + X_ScreenMID,Ypos
EndIf
Next X
Next Y
Sync
//Wait(1000)
Next Z
//UnLockBuffer
print "press any key to end..."
Sync
WaitKey
End
function ReadPOintData(Filename$,NumberOfVertex,Scale_Factor#)
if Fileexist(Filename$)
Fh=ReadNewFile(Filename$)
if fh
local Size=Filesize(Filename$)
local s$ = readchr$(fh,size)
closefile fh
// strip line feeds and eof's
S$=replace$(s$,Chr$(13)+chr$(10),"")
if Len(s$)>1
Dim FloatBuffer#(len(s$)/2)
Count=SPlitToArray(s$,",",FloatBuffer#(),0)
if Count
For lp =0 to NumberOfVertex
X3D#(lp) = (0 - FloatBuffer#(SrcOffset)) * Scale_Factor#
Y3D#(lp) = (0 - FloatBuffer#(SrcOffset+1)) * Scale_Factor#
Z3D#(lp) = (0 - FloatBuffer#(SrcOffset+2)) * Scale_Factor#
SrcOffset+=3
next
endif
endif
endif
endif
endfunction
[/pbcode]
Wow! I wasn't exactly look at it that way.
Sorry, For maybe jumping a bit ahead but this is exciting thing to me and I am anxious to move ahead. Yes, Kevin I looked back at our old code for the model loader and I seen that loading into the banks is so much faster. There is still lots to be learn here and It's a shame how so left from our community as I always find it easier to proto-type here not to mention there alot more to PlayBasic! then some know. I think it's because we are mostly known for 2D and nowadays everything is 3D but fundamentally I still comes first. As 3D is an expansion into the next dimension. Well, Steve is it sorry If I got wrong name but kevin's kinda some it up just not sure what you meant by dot/line segments? As I been looking at it as groups of chunks. And if you can show me with my demo of oct-trees an example well, that'll be cool. By to give a little heads up I'm now look forward to working on a ray-tracer for this bad boy! Don't get ray-casting hear a bit, looks like some are shooting a ray right through it and then sub-diving it up downward to the voxel. While raycasting to me means scanning top-to-bottom. But the voxels still look like on some demos I viewed blocky? or down looks lit a pixels!!!! But voxel are volume-pixels you see in my raycaster for terrain it's pixels. but what about Sizes/Scales how do I know? Some are too blocky for my liken and some seem right down to pixel like my raycaster for terrains (That I learned for a great set of books!).
That's why I want to try ray-tracing and see maybe what we!!! can really do!!
Thanks,
Scott_Bro
i thought i will post in here, the converted to "PlayBasic" version of the demo Kev put in post#6 above.
i had fun doing this, but... it only has the 2D portal rendering you can see displayed on screen. i assume this also has a 3D view, but DarkBasic has this all calculated in a matrix command set, that playbasic does not have. i could make my own up, but i guess the point of the demo is the 2D portal rendering, so i focused on just that.
all the edits i made have *** at the end of the line too. i also increased the screen size slightly because there was text overlapping the map.
i also had to look up darkbasic commands online as best i could, but it wasn't easy finding them. so i looked at tutorials and got some commands that way. the main website i checked was the thegamecreators.com older section forums.
if i modify this further, eg add 3D, i will post another version in the future.
scotty, yes my name is steve, you got it correct.
i hope this helps, have fun , stevmjon
Steve,
Cool... I dont really remember the demo now, but I think it was just a grid of cubes. It was a by product of Kyruss II (https://www.underwaredesign.com/?page=programs.Kyruss-II).. which is the grand father of PB.. History kids :)
I ended up having to write a DB compatible render (in software) for Visible Worlds (https://www.underwaredesign.com/?page=programs.Visible-Worlds)