Darwinbots Forum
Code center => Suggestions => Topic started by: Numsgil on April 06, 2005, 08:28:25 PM
-
I've spent some time figuring out OpenGL for Visual Basic. I feel confident that I can add a '3D' mode with camera controls and everything. The bots then would no longer be 2D creatures. Alot of possibilites would be opened up.
Such a mode probably wouldn't run very quickly compared to the 2D version. But I think it would run decently. I would probably need to implement some more advanced trees and things to keep collision calculation fast.
I imagine that everyone would like to play around in such a mode if it were available, so I guess the real question is what priority should this have? This is alot of programming. Alot of the physics would need to be changed to handle 3D where applicable. Does this come before mebo?
-
This is such a huge change, I don't even know what to say... :blink: :blink: :blink:
Never thought about this. First thought - bad idea. Or a good idea but for a whole different program :)
Dunno....
-
I don't imagine it would replace 2D mode. It would just be a side mode that you could play with.
-
Could be a lot of fun but I wouldn't assign it a very high priority :unsure:
-
I imagine that everyone would like to play around in such a mode if it were available, so I guess the real question is what priority should this have?
How's 'bout after .sexrepro?
:rolleyes:
-P
-
how about mebo then this
-
I think it should be fairly low priority at the moment, work on implementing the other stuff first
-
So instead of x and y, we would get z axis too?
xpos, ypos, zpos, 3d angle, new eyes or changed eyes, complex movement?
I'm for it, but if you think making 3d only in standard 2d movement, than I say it's crap...
-
I agree kozmo, its shall be xyz movements if we have 3D, sadly we cant have 4D :( why didnt we get a universe whit 4Ds :( of course I know it :D
-
Actually, it would be pretty awesome to have 3d shapes instead of circles. Maybe even have different skins - hairy, scaly, naked, scilia sticking out, little eyes rotating - would be funny as hell :) And it would be a great advertisement tool
Of course, for myself I would turn these off, but I would turn them on to make screenshots or to show it to my buddies.
-
Leave it until after you've run out of worthwhile ideas to implement.
-
zelos I have done 4D before use 4th-D as w ,
So if w is close its white , if w is far it is black. Now If you want w to be hard to see if its far away , like the z axis , then make your background black, and put a curve that favors darker shades.
There are other ways to do 4D even 5D , I cant think of them now.
The Problem is our brain maps incoming light as semi-2D , and we only see 3 colors. And that our brain only can handle 2D and 3 colors.
-
Technically it would be 4D since it has time. If you mean 4 spatial dimensions, it wouldn't be hard to do mathematically, but Bots is right when he says it's very hard to represent on a 2D screen.
You're all right about the xyz axis. Alot of new sysvars would be needed to get enough information for the bots to even figure out what the heck to do. The graphics themselves would be minor, it's all the new sysvars that would take time.
MP, I dom't think we'd ever run out of worthwhile ideas. At some point we have to buckle down and do all the inane ones.
-
the mathematic aint hard, but I mean to visual it so we can actual see the bots moveinto the 4th D. that aint possible
-
I wouldn't say impossible. It would just take some imagination.
-
it aint possible, how are you supposed to visual a dimonsion uve never seen or experienced? it aint possible. we humans cant in anyway visual the 4th spactial Dimension.
-
The mathematics exists to understand things like collisions, etc. so clearly the problem is in conveying the information to the observer.
What is available on the screen to denote spatial dimensions? Well, you have x,y, color, and distortion.
Clearly you can devise an arbitrary set of rules for how to interpret 4D, the same way you can create an arbitrary set of rules to interpret 3D on the 2D screen.
Okay, imagine this:
x,y position -> x,y position of graphic
size > z position
Darkness -> w (the 4th dimension variable). Say a bot's color is red. A low w value would result in a deep crimson. A high w value is pinkish.
In this case, a collision could be predicted by you, the viewer, if the bots:
1. are near each other on the screen
2. are close in size
3. are close in color.
-
I think the most of our problems are eyes. How would a bot know what is he looking at.
Lets say that a bot is moving on standard x, y axis. What happens when he sees a bot on the z axis. How many eyes would be needed, to bot successfuly turns to a bot on z axis.
If we have eyes from 1 to 9, then at least so many would a bot need on the z axis, 17 eyes!!!!!
9
8 X
7
6
1 2 3 4 5 6 7 8 9
4
3
2
1
X- bot in 3d space
numbers- robot view
the bot is on the x: eye7, y:eye8
But how would a bot know there is a actualy a object there?
Or we could just redo eyes in some other way?
Also there would need to be a function how many object it sees.
-
I was thinking something along the same lines.
the regular eyes scan for everything in the regular 2D plane, but extended upwards along the Z axis. So this means regular eyes can still be manipulated to turn in the right xy direction.
Another set of eyes works perpindicular to this, allowing a .aimpitch command to help the bot orient itself. Both sets of eyes work in strict 2D sense, but since they're perpindicular to each other they end up forming a grid.
But you're right, that's another 9 eyes.
The result is the bots' field of vision looks like a square cone with the bot at the point.
Here's a simple turning gene I imagine in such a system:
cond
*.eye4 *.eye6 !=
*.eye4Z *.eye6Z != or
start
*.eye4 .*.eye6 sub .aimdx store
*.eye4Z *.eye6Z sub .aimpitch store
stop
There's undoubtedly some math I'd have to look into for all this as well.
-
You would also have to make the collision detection routines work in a nested fashion (first x, then y then z). This would cost a whole lot in sim speed.
-
I'd probably have to set up a tree of sorts. There are ways to sort objects for 3D collission detection, but they aren't easy.
-
MP, I dom't think we'd ever run out of worthwhile ideas. At some point we have to buckle down and do all the inane ones.
Dammit, they're on to me...