@Wardy with the octree?

Same way. just interface your octree instead.

yeh

I dont have one lol

might wanna look into that..

when I did this style of testing before I recall that octrees came up crazy slow by comparison

ah.

Well, the Set() would be significantly slower, and the Get() is not the same either

the issue is the tree

if you are fetching for an x,y,z value, it would be slower

octree is best when you do not know the position of the object you are trying to fetch.. or if you are trying to fetch a large group of items

yeh I don't think I ever did come a conclusion about this

with an array though, your world size is limited

the only conclusion I did come to was that a flat structure meant less time digging through a stack and more time looking for the thing I want

@Jon why would it be limited ?

well... unless you are using it as a buffer

load/unload as you move around

the limit for the range of values of an int is billions

Also bear in mind that a scene would not be a single volume of data

Ah.. so you plan on instantiating a billion item array?

it would be the result of a group of volumes

that allocates memory, so the larger your world, the larger your footprint

Yeh my idea was to have the data be sourced from a function

rather than a fixed data source

so changes are not retained?

so essentially I could say "in my scene I will deal with a section of (x,y,z)"

then the generator would provide a value for each part of that

where x,y,z was effectively a view of a "virtual dataset"

yeh they could be retained

you'd have to have a seperate mechanism to store world edits

yeh i have the server system for this

this is where the chunking came in handy

the idea was that the game could be set in a virtual world of any size and the result of the rendered scene is effectively the result of a stack of functions

@Wardy I have a theory I'm trying to test...

cool :)

I'm going to a halloween store, talk to you guys later

@Wardy that sounds a lot like No man's land

the entire universe is generated off of functions

@Jon thats the idea

I don't want the size of an object to be a limit

    class Dictionary : IContainer
    {
        Dictionary<int, Voxel> data = new Dictionary<int, Voxel>();

        public Dictionary()
        {

        }

        int IndexFor(Position pos)
        {
            return (pos.x + (pos.y * Program.Size) + (pos.z * Program.Size * Program.Size));
        }

        public void set(Position pos, Voxel value)
        {
            data.Add(IndexFor(pos), value);
        }

        public Voxel get(Position pos)
        {
            return data[IndexFor(pos)];

try that instead

Make sure I didn't break any of the rest of the test

but these numbers are much better

Oh and you can change the data.Add back to the data[] format

was just testing

Still quite a bit slower but not nearly as bad as what he was getting before

hmmm

interesting

@AttackingHobo do you have anything with skeletal animation that I can has?

Apparently objects as keys are slow

looks that way

I think its because the dictionary uses hashes

if given an int the hash is not needed since hashes are ints

so the perf drives up

@MickLH I don't really have much. Want anything specific?

saves on a obj.GetHashCode() call

I tried strings and it was much faster (around 30ms) but not as fast as ints

hmmm

So ya calculating that hash on those objects must be a bear

@AttackingHobo Ideally, just a simple walking animation

@SpartanDonut looks like that's the current winner :)

I can't even rig on blender, I've spent enough time trying that I know it's easier for me to do it manually with a homemade quickie program.

I haven't even tried animating

Glad I could help

Learned something too :)

something tells me that the cost of wnating a dynamic size for the store will incur a cost

getting much faster is likely to be a problem

@MickLH its pretty easy to a basic shitty rig. To do a nice complex one. well thats hard

this feels pretty clean

@AttackingHobo When I bang games together, I give so few fucks about animations that I usually just let players slide around in T pose

hahah

To me, it actually enhances the scary creepiness of a zombie game :P

It's like rubbing the lack of a soul in your face

out of curiosity though I may try and create a simple octree example for @jon

just to show the difference

I think an octree could be useful for your engine.. however, ifyou are just testing Get(x,y,z) it will be slower

because you are comparing index VS a query

yeh that's my thinking

dictionaries still allow querying but on the flat set

but lets say you wanted to test collision detection

although because of the size of that flat set it could be slower than an octree

if you don't know what is near your entity, then an octree starts to be faster

presumably I would collision test on a mesh not raw voxel data

@Wardy please explain

but then tie the vertex that was hit back to a single voxel

@MickLH explain what ?

1. What is a flat set? 2. How is it slower?

ok ...

when asking a hierarchy for a value at a given pos you have to traverse the tree

a flat set lookup is just an index ask

I figured that's what a flat set is, and you must be talking about having a dataset so large that you hit the pagefile

well this is why its a virtual flat set

so the subset of the larger volume is derived from the function and populates my flat set

then I build my scene off that data

+ any modifications (like previous player changes)

would you agree @MickLH ?

I don't know what I'd be agreeing to :P

but, I'm on your side wardy, lol love you bro

the concept im working on is that you would say something like "give me a virtual volume that represents a .... planet that is 4km in diameter".

that would give you a volume whereby you would then say "give me a view of that volume where I want a LOD of 1 value per x"

then you would generate a set of meshes from that view

that sounds pretty legit

depending on scale different generators could used ... at orbit you want only a few values per km so a noise based texture maybe all thats needed

then as you move closer you could then augment that colour value with more detailed noise values

updating your view as you go

it means you can view either an entire planet or a simple 100 meter patch of it virtually no change in game code

all that would change is the procedural generation that goes on within the virtual volume generators

I think I agree... I'd store a list of "planets" as X,Y,Z + W, where W is the approximate radius, compute the seed from the 4-vector, and then save the rest of the player modifications into a sparse voxel octree.

But instead of mapping X, Z -> Y. I'd do it mapping Spherical coordinates -> Radius

im sort of doing that ... but without the octree

And I'd directly render the planets procedurally instead of voxelizing them

the problem with octrees is that you start to need collections of them to represent very large objects as a single octree would get deep fast

then you end up having more nodes than data

I wouldn't take the octree all the way down to the smallest voxels

assuming I want to render say ... earth at 1 voxel per cubic meter ... i'd need about 12.5 million voxels on each dimension

I'd nest polysoups or plain voxel fields once the leaf nodes got small enough

nested polysoups ?

whats a polysoup?

Mesh

i gen my mesh(es) from the volume

The purpose of the octree would just be to allow the world to be binary searched

That way you don't need to drill down the universe every frame, you just start from the voxel level that contains the camera.

start from the level that contains the camera ... so you would put the camera in to the octree

then have it traverse the nodes ?

Yes, the octree is the scene graph

Then you can exploit temporal spatial coherence to do occlusion culling, because I assume you want astronomically scaled draw distances

to get the level of detail I want I'm not convinced an octree would handle it, like I said before you get to a point where you have more octree nodes than you do data when you get deep enough down that tree

I'm convinced you simply didn't understand what I said

probably

sounds like I missed something key there

Roughly it means: You do an octree until that point where it becomes silly, then you still have a pretty big block at the "smallest" node

This coarse octree is just a scene graph, does not store voxels

hmmm ok makes sense

The "small" nodes of this graph can then have their own voxel resolution

And can also have imported meshes with positions inside

if understand you correctly then what i'm doing isn't far off from that

Then you can use your chunk generators on various octree levels

just that my views are essentially the nodes in the octree

I can say "give a me a view of this object from xyz to xyz at 1 voxel per w"

then i build a mesh from the resulting set of voxel data

you'll almost inevitably have to bubble up before you drill back down and it won't be in a nice rectangle

my thinking is that the least detailed level on something like a planet would basically just be a set of textures (various shades of say ... blue, green. white)

from that I have a base set of height data fro the surface

then further generators at higher detail levels are simply offsetting those values

so in a way you're right but im expecting the cost to be minimal

hopefully

if i can get this right

I think the chunks are the way to go man, you can generate a mesh for every octree node (yes duplicates at every level), and every level can have the same number of polygons which will implement LOD automatically. Hell when the chunk gets far enough away, you can flip the depth buffer around and render the outside of a cube, and use that box at low enough LOD levels :P

yeh thats the idea

using "dynamic LOD"

no fixed lod levels so to speak

I used a technique like that with rendering the box at the edge of draw distance, lol it works man

so I can set the number of voxels I want to see for the world at a global level then the system will allocate generation to that

sounds like I'm on the right track then :)

I copy the skybox, and render everything outside the view distance into it every few seconds. While fading from the last composted skybox to the new one.

by using functions it also means that cranking up the detail is just a matter of turning up some numbers :)

Then I cut the draw distance down indefinitely until the hardware reaches 60fps

hmmm i'll have to remember that one

I thought stuff like command lists effectively did that though in that it was a fixed cost from the end of the first frame

you could have a load of detail but the gpu had it cached

so you wouldn't have to worry about it beyond a single "go repeat this" type call

I've been working on imposters lately

and that way its real data

imposters lol ?

Yeah, like rendering a model into a texture and then replacing the model with a billboard

haha ... but what happens when you need to do collision detection or move the model ?

I combine it with bump mapping and hardware tessellation, it's another FPS booster that is almost impossible to notice if done smoothly

hmmm

@Wardy My engine considers all acceleration structures as optional

The moment it's not valid anymore, it falls back to the "slow" path

And hopefully, whenever that happens, a new accelerator that fits better is made quickly on another thread or on another network machine

sounds pretty efficient

right guys i gotta crash ... too many late nights this week im done for

@MickLH we should talk more about efficiency gains later ... I still have to reimplement threading in unity

My game is done people. If you like a casual puzzle game. Give it a shot! newgrounds.com/portal/view/647954?updated=1

I'm updating my task manager to look like the .Net API in case unity finally decide to upgrade mono

@BlueBug bookmarked for later

right im off

later all

breath quickens ok

@BlueBug tryin it now

+_+

I'm stuck on a level

I'm shooting a train of them

but it leaves the tail box

so i lose due to running out of turns

chuckles

I feel like I've tried every combination of moves

do you remember what level it was?

and, if it's weren't somebody I know who made it, I would give up at this point

having said that, I like the concept of the game

it's interesintg

:D

ty man. That means a lot.

you might want to show what level you're on when it restarts a level

there's no way for me to find out what level I'm on otherwise

might be 8 though

ok it was L9

just figured it out

but I don't understand the rule governing whether it leaves the tail or not

so I feel like my progress is goign to be random at this point

tail?.... u mean the ones that have red tail following them?

well, there's a line of 4 boxes that act like a centipede

i hit one of them, and it destroys 3 of the boxes but not the last one

ohoho

yeah that

BTW, the solution is "W D W W W..."

wtf you can press D?

oh wait, D. I was thinking S.

geez I don't even know what keys I press anymore. I just press them.

I see, you thought it was "tail" I didn't think they would be seen as connected, I was trying more of "bomb" but I see, they look rather unclear. I will work on that.

@IcyDefiance What r u even talking about xD

I don't know.

I don't know anything. :'(

must be too high from monitor light. Monitor light poison : your eyes start to lose focus then head hurts a bit then you lose sense of the world.

I got 2.5 hours of sleep saturday night, and I've been woken up too early every night since, so I haven't been able to catch up on sleep hardly at all.

so that's my excuse

dinner time :)

eat nice and warm!

I stayed up till 10AM yesterday, adding some last touch on my puzzle game thinging. Then slept around at 1 PM and now my day/night cycle had been flipped.

@BlueBug I'm on 12 I think and I can get it down to 3 guys left

but I run out of moves :(

yeah

how does the heart mechanic work?

D D W A W W A A W W

Heart means that they are about to move downward @SpartanDonut

They "bomb" in the center are actually decoy.

They exist to give illusion of "being part of the game"

o

well that's not clear at all lol

if you try to solve the puzzle using them, you will fail, on the other hands, there are levels where you will need to use those "bombs". hurhurhurhur chuckles

lol

Ok so I like it

My one critique is the mechanics aren't clear / not enough levels to sufficiently learn them before introducing something new

I was like (evil laugh) "you think you will need these bombs, but they are actually traps" when I was making that level. Ty man! @SpartanDonut

:'( I ve received that critique once before, levels being too unfriendly, not teaching well enough before introducing new stuff. I guess I really have poor puzzle level design skills. I will work on that more!

Ty!<3 SpartanDonut

Nah. Just more levels

I might be stuck on 20 lol

nevermind. nailed it

this? i.imgur.com/eewMfm3.png lol there you go! Awesome man!

me will go play some dota now ! chopchopchopchopchap!

Got to 23. My brain is calling it quits there. Good job man

Is there any reason for a game engine/framework to support both DX and GL, instead of just GL?

hurhurhur

I don't mean that as a comparison. Like if there's something only DX can do, that's a good reason to use it, but if you're supporting both then you're limited to what both can do.

u have already finished half of the game man! oh my! I am so happy! Ty!

@BlueBug hey this shit takes a lot of practice

game design is really, really hard.

you've made a good stab at it, you have a finished, playable game with a nice presentation

I will take that as... compliment! TY! <3

you're WAY ahead of the pack already

so congrats. :)

oh my dude, that's such a huge compliment for what I did. Man you know how to make a man happy with words

<3 <3 <3 Ty man.

I'm like EVE. Very hard to please, but not impossible. :)

hurhurhurhur

@IcyDefiance hey

D:

but I was trying to work on my game engine while avoiding working on my game engine and browsing reddit instead

very busy

oh shit

go ahead and work on your engine then

:)

nah I'm kidding. I was getting anything done anyway.

hahah