Clipping Issue


#1

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.


#2

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.


#3

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.


#4

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.


#5

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.


#6

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.


#7

well, good luck.
seems like hard stuff!


#8

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.


#9

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.