Now there's nothing to stop you recreating "Ecstatica", with its unique spheroid-based 3D engine.
Now there's nothing to stop you recreating "Ecstatica", with its unique spheroid-based 3D engine.
ahh so good, I liked Ecstatica a lot, I remember its only flaw was being too short, but it was so creative, so original.
Alone in the Dark was contemporary, or even earlier I perhaps, and maybe it looked better,
but Ecstatica had something peculiar that made me enjoy it even more.
Nice run throug memory lane but still no spheroids, only spheres
Not sure I can cut the shader enough to have an additional parameter for spheroids.
I might need to get rid of rotations for that, which I had been able to implement meanwhile:
This also brings more nice news: to obtain spheres rotation I completely reverted the logic, it's actually the viewpoint that rotates around the object.
This new template now should make me able to implement additional implicit surfaces more smoothly (as I can have them axis-aligned >> much easier to raytrace!) let's cross fingers
Woah this is some crazy good work. I'm speechless, pure brilliance imo
And the best is yet to come
The other main reason (beside spheres) I was particularly interested in trying this system was for rendering "boxes".
And now I can say it worked good indeed.
We already had boxes - of course, but the most obvious advantage is that now one box = one object,
whereas before we had one box = up to 6 faces
see the test scene below with about 300 boxes
each one changing animation, moving, rotating, scaling:
(you can spot some oddity - the "visibility" and bounding box pipeline is yet to update,
frame drops in crowded views are mostly due to the desktop-recording software though)
This would have been 1800 objects before!
Plus, as you can probably see, these single-shader-boxes are very sharply rendered, and there's no chance for the slighest seam.
They can be freely rotated and scaled in any dimension (width, depth, height) in realtime (this might answer casleziro request? )
without any overhead related to the operation (no need to update the geometry/vertices data as happens with current "faces").
Think at how many structures and how easily you can build by customizing and merging these boxes together.
Now a little questioning for anyone possibly interested:
since these new shapes will be self-contained in a single object,
freely customizable in edit-time and runtime through its own alt. values,
(and since they have a quite different pipeline than the current "faces")
I'm thinking about using a different qualifier -- "shapes" would be perfect,
and to drag the shape away from the map layer when the game starts,
just like it happens with "static sprites", to avoid having unneeded additional objects.
I could keep "stopped" animation as topdown view you can use in level editing to place the object,
and all the other animations for textures,
but this will also mean the object won't appear anymore in the "map" layer once the game starts,
you'd need to hard-code a map "mask" for shapes in the map layer in case.
What do P3D users think about it? Do you use the "map layer" in-game?
There's still work to do (optimizing here and there, all the collisions routines for these new shapes, trying yet other shapes..)
so this might take still a bit before I can give you - kind P3D users - this goodness.
And I'll need to tweak a bit the old shaders to make everything fit perfectly together,
so the new version won't be compatible with the old shaders, and the old version won't be compatible with the new shaders...
in short, you'd have to update both the engine and the shaders if you have a wip
but it will be hassle-free (no need to modify anything on your side, beside copying the engine group and shaders)
That looks great
This would make larger worlds and structures tons easier/performance friendly! Definitely answers my request.
To the map layer question: I wouldn't mind. To me the map layer is neat, but if I needed a map I would probably make a custom one.
Thanks for the feedback casleziro.
I think I'll go that route indeed, the advantage of having less objects and less convolution
(pointing from object1 to object2, removing object1, having textures in object2..) easily makes more pros than cons,
unless I'm overlooking something I will discover while coding
And... here's cylinders!
It was another shape I really missed up to now.
You can make columns, poles, nice structures, they are very useful building blocks and "faking" them with multifaced prisms was very resource demanding.
Now the cylinder shader is probably even a bit more performing than the "boxes" one above.
I didn't make top and bottom "caps", I could add them, but this would need having a few conditionals more,
(including the option of having or not having the caps) and easily slow down things a bit.
So I was thinking at making different shader versions for caps/no caps,
but it would be already at least three shaders (no caps, only top cap, 2 caps), four shaders for total freedom (+ only bottom cap)
this wouldn't be a big problem perhaps, just having a dozen of P3D shaders in the effects folder
(only the "dynamic loading module" would suffer a bit, as it "caches" objects and would find difficult reusing objects when so many different shaders are applied)
Same problem for boxes: adding a conditional for "clearing" faces would damage performances even more in that scenario
(even if I would obviously limit to a few options to avoid all possible permutations with 6 faces..)
So, not sure if pursuing the "lots of shaders" way, will think still a bit on this.
Now I'll (probably) stop adding more shapes and implement all the modifications needed to the engine to handle everything correctly,
and then publish the update. Additional shapes "might" come later...
Can you do a shape similar to a cube, but with a top face that slopes towards one of the four edges, and with different textures on each of the five/six sides (where each texture is a tile in a single tilemap image)? And display a lot of them at the same time...? That would be my dream
I'm just thinking that you could forget spheres/cylinders/polhedra/etc (everything except sprites) and just make it a cube-based engine (so everything is aligned to a 3D grid of cubes), similar to Minecraft but with the possibility for slopes as well, and that would be pretty much perfect (this is essentially how the original GTA games worked, and while those games used a fixed overhead perspective, there's no reason why you would have to). It would make level design and loading very simple because levels would map perfectly to a 3-dimensional array. In an ideal world, you could even create a super-intuitive grid-based level editor for it, along the lines of "Crocotile3D" ( http://www.crocotile3d.com ) or the original GTA map editor "Junction25".
Anyway, that's just my opinion. You'd lose some of the flexibility, but you'd still be able to do what most people need, and it would be so much easier to work with.
I'm also guessing it's probably not an option anyway, as it would be pretty heavy on objects, but just in case...
Cylinders came together quickly and look great.
I had been brainstorming about a way to do something similar in the current engine myself by finding a way of colliding with the actual texture images of a cube's faces instead of the built-in collision. You can technically already make a shape like this with 2 objects (although it won't collide properly):
-a cube, with top face cleared, sides drawn as triangles and front and back faces at custom heights
-a regular plane as the new top face, with X angle however you want it. This could use standard slope object collision.
The idea is to have a collision mask object that has all the shapes you would need to collide for each special case. Then this is positioned against the player object whenever they enter the 3d space of the cube and they test collision against it (face animation changed depending on your orientation, z collision handled by some trickery etc). It might be better to just use the "model" objects tied to each shape in some way, too. This could let you have some really unique shapes going on, if applied to the other shapes P3D provides.
I know i'm crazy
Huh. I had no idea the old GTA was in 3d! I thought it was 2d lol
@ MuddyMole: that customizable cube would be neat. Technically would be doable.. for sure if we had shader model 3 available
I fear this won't be possible within current available constants, and if possible (by cutting away some feature like fogging i.e.),
it would probably perform half as good as regular boxes.
I'll think at it and maybe try some testing though. Until you don't try, you never really know
Ah, as for individual graphics for "box" faces, currently not,
but I'm already at work for trying a "cubemap" texture format so you could nest all faces in a specific format inside a single image.
Still not sure the shader will allow though!
You can already have al of that of course with individual faces right now:
(jaggy edges can be improved by upscaling graphics and downscaling the cube)
but as casleziro pointed out, this won't work very good with collisions:
(try if you want)
the "sloped" vertical faces (cutted lizard faces in the picture) will behave as if they were full solid even in the missing triangular transparent area
Since P3D has world coordinates at collision point inside every touched face, this could be solved by sampling the texture RGB at collision point, if color sampled=transparent color of that texture (transparent color should be stated somewhere, i.e. in values) collision does not happen.
I thought about this as it would give some interesting new possibilities, but RGBat is pretty expensive, and it would be performed in a loop, 3-4 times x physical object (players and the ones with "fine collision" enabled) so not sure if this would cause issues.
I could make some tests if this is interesting.
As for making it a cube based engine - well, you can use P3D this way if you want
you have Fusion snap to grid, and with the new boxes the process would be as easy as now, if not even more:
the way I'm going to do it is they would have three values for x,y,z "origin" position (center of the object),
three values for x,y,z dimension (where applicable), and three values for x,y,z rotations.
I think there could be an option to auto-fill these values basing on object position in the frame, texture dimension and ratio (to read x/y/z dimension).
So within the minimal editing setup you would basically just put the cubes in the frame, snapping to grid, change z position when needed
(or use different layers for different Z positions in same objects, as some users ingeniously thought of)
As for the number of objects you can have, I'm still not sure myself right now, tests indicating 300 objects were of course meaning you can have 300 objects (boxes, cylinders, spheres)
"in sight at the same moment" (on my moderately decent desktop pc)
but you can likely have thousands in a full level, if you don't use huge render distances.
I'll have more clear data on this once the new pipeline for shapes is perfectioned.
@ casleziro: thanks!
cylinders were a quick job after the sphere indeed,
the cool thing about "quadrics" is they all look very similar, once you solve one equation, you have a template for the others.
Here's a list of quadrics: https://en.wikipedia.org/wiki/Quadric#Euclidean_space (scroll down a bit to see drawings)
not sure everyone of those would be doable (sme have a few additional parameters.. more work for the shader)
but mt next targets would be circular paraboloid (nice for hills!) and circular cones (nice for many things)