Move to adress in 3d grid.

(BluePrintRandom) #1

so each packet when it hits a switch, looks to see which direction to go, based on the directions availible in the switch

I did this kinda a goofy way and hope someone can help me perfect it

give packet adress -> send packet into grid -> packet makes it to destination

this is kinda working but not quite.


Voxel_electornics.blend (472 KB)

(Lostscience) #2

what are you making with this?

(Smoking_mirror) #3

Hey BPR, your scripts are looking a lot more readable these days but I still think it’s a good idea to give meaningful names to the text files rather than, just makes it easier to understand which text blocks are doing what.

I like the effect, it could be used to make an interesting background or title screen with some more interesting particles.

If you’re moving things in a grid you probably don’t need to use collisions, you can just work with co-ordinates.
Say your start point is [0, 0, 0] then you want to move to [0, 1, 0] you can move the object a little at a time until it reaches where it’s supposed to be going.

I use a python class for grid movement, which is given a start point and an end point and it lerps between them using a timer. The great thing about this is that you can pick up the class, get the state of the timer, start and end points and store it for a saved game. Loading is easy, just feed back the points and the timer progress and it will continue from where it left off.

import mathutils

class MoveMe(object):
    def __init__(self, game_object, start, end, speed, timer=0.0):
        self.game_object = game_object
        self.start = start
        self.end = end
        self.speed = speed
        self.timer = timer
        self.done = False
    def update(self):        
        self.game_object.worldPosition = self.start.lerp(self.end, self.timer)        
        self.timer += self.speed
        if self.timer >= 1.0:
            self.done = True

def move_an_object(cont):
    own = cont.owner
    if "mover" not in own:
        start_point = mathutils.Vector(0.0, 1.0, 0.0)
        end_point = mathutils.Vector(0.0, 2.0, 0.0)
        own["mover"] = MoveMe(own, start_point, end_point, 0.002)
        if not own["mover"].done:

A similar class can be used for rotations and other transformations so your game objects can be recorded in position, saved and then reloaded next time you pick up the game.
I use grid based movement for most of my games.

(BluePrintRandom) #4

I already know how to lerp, the idea was to simulate electronics that send data packets routed by each cube, and each cube will eventually be a devkce that can recieve these packets and operate on them

1 packet = a digital electronic burst of data
in this case of the sim each packet passes properties.

the idea is to simulate voxelized electronics

in the end, each cube will need to know all the cubes connected to it,

edit: maybe some form of 3d astar?

(Monster) #5

A* works on a graph (nodes with edges). It considers the weight of the edges.

The location of the nodes does not matter (it does not even need a location). The position within an n-dimensional space matters in some specialized solutions e.g. when you do not know the edge weights but calculate them on the flight.

Such attributes also matter when you generate a search graph from a 3D -World. The path-searching does not need that.

(Smoking_mirror) #6

Yes, with A* the graph doesn’t have to be space based even. You can do A* on behavior or colors or anything that has connections, hierarchy and cost.

(sdfgeoff) #7

I would advise abstracting your data away from 3D space entirely. Even if it is “voxelized electronics” it can be represented fully in python as nodes, packets and links (ie a graph). This will give you a HUGE performance boost, and will mean you can test it without needing BGE.