P3D 2.0 - out now!

Thank you all for the kind word and interest in P3D, it's really really appreciated,
and more so in this time when (as you see by reply times..) my computer time is very limited!
No worries for asking/bumping, this didn't rush the schedule anymore than I would already had on my own
I was trying to cut on frills anyway because of this very limited computer time,
and don't want to delay it more and more (since I was announcing it in october...)

I can take some minutes to spread some more anticipations on heightmaps in P3D though,
this is something I wanted to do from a long time but had some problems with looping on the shader
with some extra thinking, this finally proved to be possible to the extent needed
(again, thanks MuddyMole for your expertise and inspirational work, one more time!)

The main reason I wanted them much, is because they provide a nice solution to render wide terrain for no particularly high cost,
and they give chance to create organic features like hills and cliffs,
...and because I loved the look of first NovaLogic games showing a similar technology!

P3D2.1 supports 8bit and 16 bit heightmaps, 8 bit heightmaps are stored in the alpha channel of the "colormap" of a dedicated active object,
this also means both the heightmap and the colormap can be animated.
16 bits heightmaps are instead referenced as external files, while the colormap is always saved as an image in the mentioned object.

However, there are limitations of course, max heightmap (and colormap) file size is 2048x2048, which still works pretty well, graphics bigger than 4096 showed to put the system under too much stress in my testing.
This means that with a horizontal resolution of 1/4 (1 pixel in the heightmap=4 pixels in the world),
you could represent a 8192x8192 area, just like in the "mountain track" example I've posted.
I've experimented with bigger map SCALES and still holding pretty good visual results up to 6-7,
thus an area of about 15.000 pixels. Voxel maps are another story of course, since you go "blocky" you can upscale to 32, 50, 64, or even more, and have like a 32768 area from a small 512px heightmap.
Here's a screenshot of a big voxelmap area (render depth 40000, framerate captured on my laptop):

Please login to see this attachment.

P3D heightmap feature also provides collisions, realtime horizontal and vertical scaling of the whole map, two types of wrapping (standard or mirror), interpolation for map smoothing, realtime translation of the whole map, full control over the "level of detail" so you can tweak on performance or visual quality, and other options like automatic sprite leveling (for fitting sprites z position to heightmap level). For this and other features, elevation data must be ported to an array -that's the .arr file in the example posted- which is avery simple operation with an apt tool I'm providing.

That's enough for now, sorry for this long anticipation, I had to write it at some point to introduce the news

hey @Please login to see this link.
I should check that out to give a proper answer an unfortunately I can't at the moment,
but in practice if that object can output something we can read in Fusion
(and then interpret through P3D to create actives) I don't see why it shouldn't work
I used sometimes Tiled in the past and recall it had his own output yext formats, which could be parsed as well?

BUT

consider two things:

1- I still think it would be better condensing tiles together whenever possible to optimize performances so a tile editor might be dispersive/unefficient for large levels

2- (most importantly) P3D has now its own "level editor"... and you can already get it here:
Please login to see this link.
I made it in a couple weeks on january but then I fell in this wormhole which drained away all of my pc time so couldn't refine it as I wanted,
but still, it is perfectly useable. It was born as a simple top-down triangle mesh editor (that's why I called it T-mesh) to help me prepare the new examples,
but since it got quite nice I made it more powerful, added also quad meshes, boxes, cylinders etc and is now practically a semi-complete level editor for P3D.
Still misses important features I'd love to add but it's really fast and productive already.
Its output requires P3D 2.1 to be read but you can play with it (and save your projects) anyway, to gt the feel of it.

I was willing to make a short tutorial video.. 15 minutes would do, and hope to make it soon,
but here's the general workflow for anyone willing to try it:

1- pick a color from topright wheel (a color that defines the material you are about to paint with)
2- add a description for this material and click "add material" (you can add as many as you want, these will become your different textures)
3- pick a shape from the little scheme under the material list, and plot it (if it is a mesh) or add/draw it (if it is a 3d solid)

there's much more to say and no docs currently XD but there's some info at the bottom of the screen while you hover around.

Once done, you can save your project and/or export to P3D
(this is the tool I used to make that little scene I posted few messages ago when testing for triangle seams)

hope you enjoy it!

@Please login to see this link. : heya man, it's been a long time :)!
If you are interested feel free to drop me a pm, 2.1 version is ready (from long time..) and betatesters can play with it
I hope to find time soon to complete those couple missing examples and release it for everybody

If I understand it right, that shouldn't be a problem,
I think this could be the workflow on P3D side:

1- prepare your tiles in P3D (active objects being walls, pavement, etc., made with 3D objects qualifier or the new "Shapes" qualifier) and untick "create at start"

2- prepare a loading code to generate the tiles from Tiled editor,
I'm not sure on what kind of output you have here, but what you basically need is:
tile name|xpos|ypos|zpos
if you can output this data, in any kind of format/arrangement (then you can easily make some string trickery in Fusion) than it surely can do

3- put a "start of frame" event to fire your loding code,
or deactivate "P3D" group and enable it after your creation code has fired,
P3D will start up and create all the 3D elements from the tiles you generated

side note:
T-mesh can also be used with "boxes" (cuboids) and has a "snap to" function,
so I think that could be handy for this kind of games too (you can "draw" walls and pavement by stretching cubes)
but I can surely see how tile editing in a proper tile editor can be very comfortable!

That could be doable as well I guess, if you can procedurally export textures from TilEd
(or pre-store and arrange them) then you can import them in cubes with "load frame" action,
or maybe even better,
put all textures as separate animations of the cube (shape=box in P3D 2.1)
and then when loading the tiles with t hat "loading code" we were talking in the other post,
simply set "my_animation" value to the exported tile ID

if TilEd gives out the right data, it should be easier to do thank to write down XD

Hello CheatingPenguin,
glad you are enjoying P3D!
(and sorry for te delay in latest update which will vastly improve the engine)

In the screenshot you posted, you can see there's a button on top right of the expression editor, named "use expression"
if you click there, you can enter an alterable value "index" >> so you can access values by number,
thus you can simply click that button and enter 69 / 70 to address values 69 and 70

Fusion allows you to use unlimited values in active objects, but you can only name 26

Hope this helps and feel free to post here if any issue!

Thank you 3DBBQ!

I'm sorry I've just seen your questions now:

1- yes, 2.1 will bring improved performances, mainly due to the introduction of the new "Shapes" qualifier, which is on average about 30-40% faster than current 3D Objects + 3D Data, and most importantly allows to drastically reduce the object count, when using the "box" shape you can save 6 objects for a cube, so that's a relevant improvement.

2- the mouse question: I'm still not sure on the issue, you tried to implement the mouse-lookaround code in a project but it didn't work out as expected? If this is the case, feel free to send me the file at the support email (you find it in first pages of the manual) and I'll check it out!

Hello Ben!

Wow, that's a very nice idea and thank you for creating the channel,
I had received a similar suggestion some months ago and will spread the link for a P3D support channel once 2.1 is finally available,
but of course it's great if there are different P3D places for tutorials, talking and idea-sharing!

Very nice buildings you have there

That's a neat idea for "double-faced" textures.
It would be doable, shader-side, maybe by "nesting" both textures on the same image,
and telling the shader to sample one or the other depending on which side of the surface is shown.
However, this would require a modification to an already "full" effect and I strongly suspect
it would be necessary to "sacrifice" some feature (i.e. glowing lights or global lightness or transparency)
to make some "room" for this extra operation.
I will consider this for the future and maybe make some test when possible!

For semitransparency, you can try this:
identify the "Data" object that needs to be fixed (the "glass" texture basically)
and then add an action like this:

(glass texture) is visible
>>> (glass texture) bring to front

see if that makes any change!

The reason is the depth buffer stores a "depth" value for every single pixel on screen, and whenever in the same "draw cycle" (frame) a new pixel with nearer depth is found, the new color and depth values are overwritten.
When the object is transparent, no color and depth are written, but when the object is semi-transparent, values are allocated, and if the semitransparent object is drawn before the objects "behind", they won't be drawn on screen because their depth values are "further".
The trick is telling DirectX to draw semitransparent objects for last, so they will be drawn "over" already drawn objects behind,
in Fusion you can do so with "bring to front" (>>> draw as last)

I suspect it works fine with very high levels of semitransparency because it actually deals with it as if being fully transparent.

I thought of an automated routine to deal with this, but the fact is it would have been very intensive, and so I thnk it's better fix it manually when necessary.

Not sure about the collision question: you want the players to collide or not against the transparent object? Or to make it "dynamic" (open/close..)?

ahh sorry now I got it!
I think the most comfortable way would be specifying "obstacle_type" as "mask"
and then make the parent 3D object graphic as if it was an open door seen from above
(a segment with a hole in the middle..)
the downside is you won't be able to specify the collision area for the wall above the door,
but if your player can't jump/fly that high it couldn't be a problem maybe?
If it is, then you'd need another 3D object to put a collision block up there, and make it invisible, like you were saying.