Yet another possible bug…
I’ve been in the ongoing process of testing out the elements of a large open scene, and the camera clip is becoming a bit of an issue. I can’t scale the camera down without having to engage in insane mesh detail that will not work accurately for my purposes, but the clipping option at a normal scale has issues…
~100km: tearing at the edges of planes. (regardless of vsync)
(long and heavy animation, ask for google drive link if you want to see.)
~1000km: uh…
~10,000 km: float division by zero.
At other clips I’ve observed objects smearing across the screen, etc. (See
here)
Unless there is another setting for it, I take it this is something for github issues?
My other alternative is to adaptively scale all the objects, but it would be very slow, because there will be maybe ~2000 other objects to keep track of at peak usage, and there’s already a lot of logic happening; my time data from haxe shows I’m eating up quite a bit of the frame. (Also, the FOV would look off)
Anyway, another opinion would be nice before I make a bad decision and spend my little time developing the slowest option. Thanks in advance.
the thing is armory uses float values that are limited to an artificial maximum value,
and since blender uses double values, armory is limited.
@lubos, maybe take a look.
2 Likes
It would be amazing if the only action I had to take was to change all of the floats in the source code to an obscene base. If that is possible, I might as well get started.
Ok, from my research that might not work, you can only change precision and only so far. What might work is to implement some sort of chunk loading for the renderer, but that’s a bit much to ask for, and I forsee horrible emission issues across chunks. So unless @lubos is able to find the magic third-party type that I haven’t which extends the limit to several million meters and then implement it, I’d say we need some other kind of workaround.
Possibilities:
Adaptive scaling (Actually really slow, would need to edit on a per vertex basis, probably won’t look that real, especially with fov)
Giant camera texture projection in the distance (emission wouldn’t work, at least without gi i’m pretty sure)
Miraculous type found. - I could try to code this myself.
Whatever creative solution you can think of.
A bottleneck with a new type is that the haxe code will also need to be updated with this… Somehow. I’m not going to pretend to understand how that language works on the inside. At all.
One thing to note is that the orthographic camera is not affected for the most part and can withstand amazing camera clips before it breaks. Might be useful to keep in mind in the future.
Best case scenario it’s a bug and the great god Lubos can see the light.
1 Like
So I’m not very good with Inkscape, bear with me. Below is a concept drawing of how I can greatly increase view distance.
Essentially, red cameras cannot see blue camera projections, and likewise, blue cameras cannot see red camera projections. It should be fairly easy to code lights that spawn on the projections to mimic shadows accurately, too. However, I have no idea how I would make objects selectively invisible to various groups. The alternative could be to try and see if the individual camera background image can be set to the next camera’s image. (Although I think it not possible.) The camera background might be slightly less computationally expensive, but I don’t know how to do it.
–EDIT–
Silly me, the viewscreens would be flat. Just pretend they are.
Ok, setting up the FOV in blender so it doesn’t distort is basically impossible (unsurprisingly though). I can’t do adaptive scaling since it’ll be too slow… Darn. I’ll go peruse the source code.
well, good luck.
seems like hard stuff!
So I tried getting the thing to work in 0.5 alpha.
100 km:
I noticed very little tearing, and only on the large object, so I can try tearing things into chunks to stop that. There was a little relight delay where the shading would seem to shift into focus, but the bug looks stylistic, so at the moment I don’t care.
1000 km:
A mobile game is telling me to put on a sweater.
I might be able to manage 100km with adaptive FOV at a distance, but it would take a lot out of the game, as it’s oriented around very small details.
Anyways, that’s a quick synopsis for those concerned.
K, I figured I ought to updated this… Talked to Lana Del DK on discord, who figured out I was suffering from z fighting. At any rate, lubos said he’ll do a logarithmic fix for 0.6, so I’ll post again when it comes out and I can test it.
Just found a messy but very functional workaround in 05 b28. Make sure you’re in the forward render preset, and create a giant plane with a couple of kilometers between it and your enormous view clip that obscures the background (in future a sphere will be much better). Then the only z fight will be between the background and that plane. To fix background z fight, you head to ./build_(name)/compiled/Shaders/world_pass.vert.glsl and add the following in main():
gl_Position.z=log(gl_Position.w + 1) / log(1000000/*my view distance*/ + 1) * gl_Position.w;
//might also work just to set it to a constant
Beware - switching to defered will delete the file and the background will break again. There probably is a place that the logarithmic depth of the background for deferred can be added, though.
I only halfway understand why this works, but it works like a charm.
2 Likes
There is an issue with the above solution in that offsceen stuff will bleed onto the screen because it’s not cleaned up. If you create a plane in front of your camera and cut a hole in it you can solve this though.
Doesn’t seem to work in C++… Refuses to render giant plane. 
try moving everything to a new project. but before doing that, take a break from this project.
that anger emoji says everything.
Thanks, might be useful to step back a little… At any rate, I was planning to use peer to peer with webrtc sooner or later, so html/krom is fine for this particular project.
