Build A World - new massive game, using Irrlicht

[devsh]

http://creativemachines.cornell.edu/sit ... _V0.47.pdf

Information wants to be freee

[devsh]

we've hit quite a brick wall...

Seems 3D printer software is utter crap(regardless of company, they all suck), regarding HI-Poly meshes... even after optimizing our mesh in blender (mergining all faces in the same plane into one, reducing triangle count by factor of 6 and vertex count by 30) we have found that it takes 1-2 HOURS FOR THE SOFTWARE TO FIGURE OUT THE PRINT VOLUME (how to move the nozzle to create the layers). Despite providing it with a watertight, non-intersecting etc. etc. mesh.

My main suspect here is the fact that the software does floodfill/voxelization on the CPU.

Only hope we have left is that .AMF performs better, or that we can export GCode (calculate nozzle movements ourselves, or that we can cooperate with the printer and software makers on resolving this issue.

[devsh]

false alarm, apparently STL doesn't respect normals and uses Z-up convention which f***s up triangle winding orders... so entire mesh was inside out.

[devsh]

It takes BaW 24 seconds to make a REALLY big mesh (3 Million tris on an area 512x128x512)

as a BINARY STL its 150MB and there is nothing you can do about that, as an AMF (which is basically a zipped XML) its only 19.6MB (despite the fact its a whopping 368mb uncompressed XML).

When you load it into Cura it will take about 3 minutes to show up.

Then it will take about 8 minutes for Cura to figure out how to fill the model in Ulti-quality (bear in mind that its a large model requiring a lot of slicing and paths to fill -> 195.2mm X 195.2mm X 69.0 mm)

One thing which is very annoying is that when you move or scale the model it becomes totally unresponsive (they need to learn about drawing meshes with Transform Matrices).
Probably because they need to transform every vertex on CPU and save it for the slicing algorithm.
Which leads to a funny situation when even if you have instancing/constellations, it still recalculates the gCode fills for each instance (something which they havent thought to optimize yet, I guess).

In the screenshots of the 3D printing preview there is one green arrow and two blue arrows.
Might be a mistake since normally for coordinate axis there would be one green, one blue and one red arrow.

The only way you can move the model is in the 2D plane, you cant move it up or down (as then it would be floating-off the printer bed).

Furthermore the print preview can be improved:
Please allow the arrows to show where the axis positive side is, no two way, symmetrical arrows please.
Please allow for showing multiple arrows for exporting (one set of arrows showing BAW's internal coordinate convention other set of arrows for the formats convention, multiple sets of arrows for multiple formats allow with a dropdown menu in the preview instead of determined by export format)

The screenshots of the 3d models are from the respective printer softwares, its not inside BaW!

[devsh]

Its alive

[sodandk]

That picture was of the print half done ....

[sodandk]

working on making coal/oil/wood burner for powerplants...
need a dynamic conveyorbelt-system for coal transport

work in progress:
https://www.youtube.com/watch?v=nrl2NcUUDGQ

[sodandk]

https://www.youtube.com/watch?v=V7FKpce1L0o

[sodandk]

Fossile fuel: https://www.youtube.com/watch?v=0dHOGO5inPc

[devsh]

Finally I've started experimenting with raytracing for direct visibility!

[devsh]

This a visualization of ray-tracing cost for marching a volume of 1024x384x1024 voxels for direct visibility

This gets an FPS of 109 worst case, the original had an FPS of about 40 with only 448 voxel render distance (but with reflections in water) and it required around 20M triangles!

This is without cone tracing! Where blurring the output makes the cone trace faster (wider cone).

[devsh]

Okay so I found out that I could use the log() scale on my cost of tracing and invert the color to get a fake AO effect



For the lulz I decided to trace a secondary cone from the end of the first to simulate shitty shadows



Then I corrected my skipmap and stored it in a single channel texture and only sampled color+opacity when skipmap would say i'm inside a solid voxel or less than 1 block away
This tripled the framerate!!!




Finally I thought, "what if I make everything slightly transparent"

OIT is HERE, in OpenGL 3.3

[devsh]

So we found out that we can go 220 FPS to 660 FPS with 2 weird optimizations

There is a 3rd one but that depends on how one can improve early fragment tests over the current GPU solutions

[sodandk]

in progress ... instanced everything.

here are corn, 40.000 plants running 72 fps

[sodandk]

.........