P3D - a framework for 3D applications

Love it
Can the Camera look up/ down?
Can the tile sizes be smaller ( to make for smoother light distrebution ), or will this slow things too much?

Thanks King_Cool!

Yes, I'll make camera look up/down in next part of the tutorial
(gosh- got me 5 hours cooking first part, I wonder how Sparckman does XD)
anyway, it is as simple as changing "X_angle" or "Y_angle" values in the currently selected viewpoint object
(a little limitation: backprojection may throw in some extra distortion in very near tiles, closer than 16 pixels, crossing front-back view pane, when bending up/down)

Tiles can be smaller, but as you say having a very large number will slow things too much.
It's safe using some of them (i.e. to fill gaps)
but i.e. using only 32x32 tiles showed in testing to saturate the available headroom a little too quickly
making for "smaller" renderable scenes

I think the only solution to my problem is to use single clicks and change it over to a stamp system rather than a brush system. Fusion seems to be skipping collision checks for overlapping when I try this which I think is why we're getting this bug (the create tile loop is running when the delete loop does- results in 2 tiles being produced and deleted without their polygon being switched off). So Instead I'm opting to change to single press instead, I feel it'll be less clumsy, but may be more tedious as far as clicks are concerned.. but less tedious than having to reload the entire level when a dead polygon is loaded.

Results fantastic either way. Video here https://youtu.be/14q1NukAnf4.

looks nice MrCyberpunk - youand schro should team up!

Quick update, got the brush method working instead, no more stamp required. All I had to do is limit the draw to 0:15 seconds. Apparently it was running the code too fast which was creating duplicates. Fast Loops reduced the number of errors I was getting (before I would get 50% dead polys) whereas with Fastloops I only get 1 dead poly, and only ever at the end. Limiting the draw seems to fix that so that I never get dead polys.

https://www.youtube.com/watch?v=tUYjcjK5kMY
Video shows Nightime Editing, and transitioning from Edit mode to Play mode. Note in play mode the 3D cursor now disappears (you can do this by setting X position to -1000000 which prevents it from rendering I couldn't figure out how to unload the polygons, so this is just as good).

EDIT: on further testing the bug is still occurring. I notice sometimes the cursor just freezes. Still going to say this is Fusions collision detection bugging out. I tried using Math to do it, but ultimately I ended up with a worse result. I'm afraid I'm probably going to have to just live with this, but limiting the draw definitely reduced it.

EDIT2: I also limited drag length, this seems to have made the problem even less likely to occur. I rarely see it now (only time I've seen it is when I mash the mouse button to draw.). - yeah I feel a lot more confident with this now, doesn't feel like its going to break.

That's cool! :D

If you need to hide some projected element you can also use the "blend coefficient"
stored in alt. val. 38 of the texture (group. data),
or if more instances of same texture exist,
"scoping" that (alt. val 26 of group. data= fixed value of "parent" 3D object)
that gets updated dynamically so can be changed during runtime

But setting position far from viewpoint (farther than render_depth) is definitely a good solution
it also saves the polygon from being projected

Bought it, very nice! On the 1.101 example, I notice the player gets stuck if walking close to a block and doesn't walk along-side it, and can even get stuck. This was the first thing I tried after running the mfa. Is there a way to have the player slide along the block when touching it and walking instead of getting stuck?

Thanks elvisish!
Currently, with standard movements supplied with the engine - not.

You can of course code your own movements for any object and implement a custom solution, if you're willing to try.
I remember while working on movements that main issues were providing collisions that worked reliably with the additional Z-level among different planes
(object colliding with multiple object at multiple heights at same time).

But I agree with you wall-sliding would be nice :)
since I'm close to release 1.2 update
(with cool news -> one of them likely* being a noticeable speed boost due to various optimizations)
I'll try to see if I can get something working along that line also!


* it's quite noticeable (+8/10 fps) on the couple machines where it's been tried on,
still not widely-tested though!

Thanks schrodinger! It looks great, I noticed a few fps drops when I get very close to objects, which is strange as usually frame drops happen when many objects are in view rather than one object up close, any ideas why?

Indeed this is odd! Drops should happen in "crowded" situations, as you say.
Did this happen in one of the examples included?

Could you point me at the example/situation (facing the south face of building xxxxx)
so I can take a look and see if there's something specific,
or does it happen "generally" with any 3D object you get close to?

Btw - "few" drops, around 2-3 or more like 5-6?

Thanks!