Automated support calculation + "greyscale" curing and variable retraction speed

[dgm3333]

I believe there will be a day when consumer SLA prints "just work" without massive user hassle. I am therefore wondering whether UVTools could be used to bring that day closer by automatically creating far more sophisticated supports in a much more than the "standard" sprue and attachment cone that typical SLA slicer software offer.
Typically people seem to spend up to an hour adding and subsequently removing supports to a model. Even at $10/hour this would be equivalent to 100-200ml of resin, so if you could create virtually guaranteed supports which were automatically added and easily torn off (thus saving time) then such supports could actually use a large amount of resin and still be cost effective, and you could potentially even calculate and control the "failure probability" to manage the balance of cost for those more or less time/$ conscious).

Given a voxel array, it should be fundamentally very easy to start at the last (highest) voxel and calculate the tearing force it would exert on the voxels directly under it when releasing from the FEP. You could then sum the support strength of fully/partial cured nearby voxels to establish the minimum number of voxels and the cure level of each support voxel and repeat down the model until you get to the base support layer. This would then identify islands or weak/risky structures requiring additional support.

It should then be easy to create cocoons around a model which could trap a 1 pixel layer of uncured resin to generate viscous traction on the model while locking the model and reducing oscillatation which increase risk of premature release. This cocoon could have strong buttresses feeding down to the raft, and vertical fracture lines to enable easier removal, and could even sit directly under bridges (to generate vacuum traction and assist FEP release) or wrap over top of particular key components to help transfer force from the raft to the component.
You could also perhaps cure a ring of voxels at the edge of islands leaving a single layer uncured region directly below which might provide sufficient viscous vacuum to lift the island from the FEP with less actual bonded support voxels than a traditional large faced sprue.

If the printer firmware could read a greyscale file format to only partially cure support voxels (ie a 50% gray voxel could be exposed for 1/2 the time or half the intensity of a 100% (full white) voxel before the next lift), then it should be possible to even more finely tune the supports - eg a partially cured voxel could still provide support but would be weaker and therefore provide a shear plane to allow easier removal of supports, and perhaps even one which could be tuned to be automatically broken by frequencies from an ultrasonic cleaner, or dissolved by IPA.

In areas where pure viscous support would be ineffective (eg for islands) then you could partially cure some of the underlying voxels to allow enough support to hold the island while minimising damage to the island face on removal. This should also mean that even single voxel islands could be supported and safely extracted by fully curing the ring of 8 voxels below it while only partially curing the voxel directly below (-z) and lateral (x/y) to it.

If you could utilize a greyscale cure then it might be possible to have supports which are strong during printing, but have significantly weaker attachment to the model after ultrasound or IPA exposure, and either fall off or can be removed with minimal traction.

There also seems to be a lot of advice to tilt models to mimimise inter-layer tearing due to traction force but the raft layers are generally much broader (and therefore breach this general advice from the outset), however if retraction speed could be controlled and vertical pull-apart lines built into the support then such considerations might be unnecessary anyway and the model might even be able to be placed directly on the base.
In addition (if you wanted to go really mad) it should be possible to modify the FEP traction force on particular points of the model by controlling the structure of the support around them.

I'm also not sure why most printers appear to have a fixed rate of lift for every layer - surely if a layer has a larger surface area, or voxels which were relatively weakly attached to the underlying layer then it would make more sense to slow down the retraction for that layer so as to keep the moment force on the underlying layers below a fixed range - this should enable an increase in overhang angle or bridging distance and much better control to minimise the risk of a model tearing apart while simultaneously minimising overall model print time (not forgetting that print failure is a massive time waster). The retraction speed could be easily defined by the slicer using a fixed greyscale pixel in each layer to encode the retraction speed - column x0,y0 isn't normally used in a print so should be good and the firmware could set each layers' retraction speed from this grayscale column. Admittedly even if a second layer retraction file was required for the print then computed retraction speed this should be able to decrease print risk.
Alternatively if you could encode a "maximum safe retraction force" in the file then if the printers were fitted with a torque sensor on the baseplate arm then it would also be possible to automatically slow down the retraction if torque approached that force to again decrease failure risk...

David

[sn4k3]

You have done a great papper here, but i have to admit, some of the concepts, problems and solutions you describe i don't understand them as i'm not an active user of resin printing, only printed 2 simple models so far so i never had problems or complex models to deal with. Auto supports for me always worked but i belive in some complex situations it will not work best. If you could illustrate each problem/solution with a picture or samples would be great for me. For example a model supported with your "cocoons" ideia which i cant visualize atm.

I belive all this will be more a work for slicers, there is where things are all made, UVtools is just a healer/checker that work in the 2D space, and most of what it already do it should be done on slicer, it have no voxel information nor notion of 3D space. While is possible to rebuild a 3D space from 2D layers, that is much slower compared to slicer working with stl files.

"If you could utilize a greyscale cure then it might be possible to have supports which are strong during printing, but have significantly weaker attachment to the model after ultrasound or IPA exposure, and either fall off or can be removed with minimal traction."

UVtools already do that if you want, Tools -> Redraw model/supports. There you can adjust the bound of support tip to model with grayscale. It will be easier to remove supports, and when you find the correct value for your printer you can remove easy them by hand.
This is one of the tools i dont know why slicers dont integrate it, it's so simple as have a input box to let user input contact intensity...
Example:

On next version of UVtools it will support in GUI scripting and access to whole UVtools core, layers and file formats, you can start doing some experiments and try to implement some of your ideias and share back or coop as you can test/execute/inject code in real time.
Changing retraction and speeds will be super easy to do and them we can official put it on the Core. I was about to implement a mass dimmer depending on area thresholds etc, so it would be the same for spot larger areas and put less speed for retractions.

I'm also not sure why most printers appear to have a fixed rate of lift for every layer

Because that "little aspects" don't matter for them, it just a bussiness and most just want to sell it and have "easy formats", most firmwares are trash and most file formats are too as they are to many restricted.
Most printers do grayscale, and the recent printers are starting to allow per layer settings: https://github.com/sn4k3/UVtools/wiki/Printer-compability-with-per-layer-settings-and-advanced-tools
That's why gcode printers win in this "tech" space, you can do any kind of manipulation and tweaks to printing while if you go .ctb or other binary encoded format your are grounded to that, but there is hard to find good gcode printers. If i would buy one would be an Uniz iBee because it seen to have good hardware and its gcoded.

[dgm3333]

By "voxel" I just mean the small cuboid which makes up each point in each layer. You might call them pixels (as they are flat when drawn by UVTools) but we are referring to the same thing.
Curiously, how does UVTools identify the resin traps if it isn't aligning the layers - it looks like it's just identifying a potential trap on one layer then looking up or down to find if it's still trapped on subsequent layers - my suggestion is very similar to this strategy.

I'm not sure I agree that the analysis is easier to do with STLs or g-code - that's one reason I've never done it - I couldn't analyse the traction on STLs or gcode without complex 3d maths, but the pixelated SLA files are vastly easier. But I do agree that it's a shame the existing slicers don't already do the error correction that UVTools is doing - its approaching 20 years since Reprap really accelerated the consumer 3D printing trend and the tools remain primitive in that respect - and it's not like there isn't a massive engineering industry already doing this sort of stress analysis in real-world construction.
Here's a list of some of the free finite element analysis software which have strategies appropriate for calculating and minimising stress within a print https://en.m.wikipedia.org/wiki/List_of_finite_element_software_packages#Free.2FOpen_source
(I'd probably also consider openfoam as it can also do stress analysis and isn't limited to static states (since the print changes over time fluid dynamics might be appropriate) - https://www.openfoam.com/)

*** Supports ***
This isn't necessarily an ideal example for automated supports but gives the general idea
The three colours represent different support types

Red I-beam
This should be stronger for the same mass than standard cylindrical sprues. Because printers tend to peel in the y-axis as the lifting force tips the baseplate downward at the front then you would expect to need more strength at the back and less strength along the x-axis (which is why it's an assymetric beam). The "filleting" in the corners where the x and y faces meet to to assist force distribution.

Green apron
Assuming the circular structure surrounded by green is an island, and that the green would extend a number of layers below, something like this should have OK (but not great) adhesion to the larger structure. It would need testing but I'm hoping IPA, USS cleaner or microwave exposure would cause the surface layer to flake off, but if not then there are edge "grips" to help it peel off. If traction was required it would need to be thicker than 1 layer or you couldn't peel it effectively but that's the general idea.

Blue wall
This would be what the potential support on an underlying layer would look like if the overlying arm needed such - the zig-zag adds strength while distributing force over a larger area - This could be used underneath any bridged structures and could be built up as an arch from any sides available (if the apron worked) or from the baseplate if necessary. I guess for model makers the bottom edge of a cape or the underside of an outstretched arm might be a good example where something like this would be needed. A horizontally set circular hole would similarly likely need support as the bridge closed in at the top.

*** Stress analysis ***

I started on a pseudocode mockup of the stress analysis code - although I thought after I did this that there might well be good open-source engineering "stress analysis" examples out there already (listed up top of this post) - I'll have to look around. However although it might be feasible to simulate the print into something like openFoam to calculate a highly realistic voxel force transmission profile it wouldn't make for a simple or efficient toolchain ...

The force transmission and proportions will definitely need tweaking, but these are a rough guesstimate to start off with
//They should definitely be verified experimentally and would almost certainly vary with different resins

Define the raw forces
// FEP exerts traction on the single voxel it is in direct contact with - whether set or unset.
//Two stacked voxels must be vertically "glued together" more strongly than the traction the FEP exerts on the voxel - otherwise every voxel would remain attached to the FEP.
// since a tower would typically break off the baseplate before it broke in half this is typicall stronger than FEP but weaker than inter-voxel binding force
FEPTractionForce = 5
voxelBindingForce = 10
basePlateBindingForce = 7.5

// Now define the proportion of force a voxel exchanges with surrounding voxels
//For initial simplicity it is assumed a given voxel will only cause traction on a voxel in direct contact with it, and that the binding force and traction forces are proportional
//This is obviously wrong (eg a bridge transmits force along it's full length)
//This process could be made more accurate by itteratively recalculating (effectively spreading the force over a wider area) until a "minimal change" was achieved, that might be quite computationally intensive, but users could define their own thresholds for this, and potentially have an "complete stage now" option to break out of such a loop...
// Also assume it will only transmit downward towards the baseplate (this is clearly incorrect but in most cases retrograde forces are not relevant to printing)
//forceTransmissionMatrix provides a rough approximation of the relative traction that would be exerted on a voxel if all surrounding voxels are present
It will be assumed that if a pixel is not present it's proportion of the force will be proportionally divided amongst all remaining pixels
forceProportionTransmissionMatrix = {
// current layer
0.25, 0.5, 0.25
0.5, 0, 0.5 // 0 = current voxel (it doesn't exert force on itself)
0.25, 0.5, 0.25
// layer above/below
0.12, 0.25, 0.12
0.25, 0.75, 0.25
0.12, 0.25, 0.12
}

// Different cure rates will transmit different levels of force. This is defined as a function (to allow compensation for grayscale curing)
CureProportionalForceTransmission = 0.9c+0.1 // where c is the proportional cure from 0 to 1

//This array contains the maximum traction a given voxel will experience. Ultimately the binding force for a given voxel will need to exceed the traction force or that point in the print will fail
voxelMaximumTraction = { 0, 0, 0, ...}

//First calculate the CPFT for each voxel in the entire 3D array and store in a reference array
CPFTMatrix = c*CPFT

//start at the baseplate layer then step up to the last layer
assign each voxel in the top layer a traction force of FEPTractionForce * CPFTMatrix[voxel]

step through every layer below the current top layer
    calculate the Total Force Transmitted into each voxel by the 8 surrounding voxels in the same layer and the 9 voxels above the current voxel using the FPTM to proportionally assign values for the spread of traction down through the matrix
    if desired the spread could be repeatedly recalculated using the latest force value until change dropped below a certain threshold to simulate force spread to more distant voxels.

when force calculations+/- all iterations finished then compare result against voxelMaximumTraction.
if TFT >  voxelMaximumTraction[voxel] then update the maximum for that voxel

[dgm3333]

Here's another example - with the supports a human designed :-) vs those the slicer creates :-(
The autosupports alone not only used nearly twice as much plastic as the original turbine (ie autosupported print was 250% of plastic consumption cf human version), 25% more time to print, caused more damage to the turbine, and didn't actually provide as good a support but (to add insult to injury) it also extended beyond the edge of the buildplate meaning there is a risk of edge shearing !!)

[dgm3333]

This obviously isn't finished code, but I've started to experiment with options (it's not bug free or remotely accurate yet so it's just the next draft of the idea. (sorry I've never coded c# so it's in traditional c)

// StressTestAndSupports.c
// Down the line it should perhaps be integrated with a more powerful FEA (Finite Element Analysis) library such as deal.II
// But this requires more engineering / math than I have at this point, and I'm not sure if it would be dramatically more accurate than the current "brute force" approach.

#include <iostream>
#include <map>
#include <vector>
#include <string>


// Different cure rates will transmit different levels of force. This is defined as a function (to allow compensation for grayscale curing)
// Withing a voxel this will be different closer to the printface vs further away (due to UV drop-off away from the cure face)
// This is primarily accounted for in the force transmission matrix
// But if it turned out to be disproportionate at different cure rates this function might need to be more sophisticated
float CureProportionalBinding(float c) {
	return 0.9 * c + 0.1;	 // where c is the proportional cure from 0 to 1
}

float perVoxelBuildfaceTraction(float r) {
	return r*r;	 // where r is the rate of retraction from 0 to 1
    
}


int main()
{
    
    const int X = 0;
    const int Y = 1;
    const int Z = 2;
	// generate an array containing the model
	//					z,     y,    x
	int rangeZ = 10;
	int rangeY = 21;
	int rangeX = 38;
	//char buildvolume[1000][2160][3840];
	float voxelCureLevel[10][21][38];
//	float voxelSupport[10][21][38];
//	float voxelSupporttmp[10][21][38];
	float voxelForceVectorXYZ[10][21][38][3];           // the xyz magnitudes of the force vector for each voxel 
	float voxelForceVectorXYZtmp[10][21][38][3];        // temp store of xyz magnitudes indicating impact of neighboring voxels force vectors
	int voxelsRequiringSupportXYZ[1000][3];             // a list of the voxels requiring support
	float voxelsRequiringSupportXYZSupportStrength[1000];  // the strength boost required to provide sufficient support for the voxel
	int voxelsRequiringSupportCnt = 0;   // how many voxels actually require support
	for (int z = 0; z < rangeZ; z++) {
		for (int y = 0; y < rangeY; y++) {
			for (int x = 0; x < rangeX; x++) {
				voxelCureLevel[z][y][x] = 0.0;
				voxelSupport[z][y][x] = 0.0;
				voxelSupporttmp[z][y][x] = 0.0;
				voxelForceVectorXYZ[z][y][x][X] = 0.0;
				voxelForceVectorXYZ[z][y][x][Y] = 0.0;
				voxelForceVectorXYZ[z][y][x][Z] = 0.0;
				voxelForceVectorXYZtmp[z][y][x][X] = 0.0;
				voxelForceVectorXYZtmp[z][y][x][Y] = 0.0;
				voxelForceVectorXYZtmp[z][y][x][Z] = 0.0;
			}
		}
	}

	//create a test shape in the buildvolume		// inverted triangular pyramid					// (next try stellated dodecahedron)
	// NB this will fail with certain build volumes (eg if z>0/5y) - so don't consider it robust - just for testing
	for (int z = int(rangeZ/10); z < rangeZ - int(rangeZ / 10); z++) {
		for (int y = 0; y < z; y++) {
			int startX = int(rangeX / 2) - y;
			for (int x = 0; x < y*2 +1; x++) {
				voxelCureLevel[z][y+ rangeY / 10 - int (z/2) + int(rangeZ/2)][startX+x] = 0.9;
			}
		}
	}




	//The force transmission and proportions will definitely need tweaking, but these are a rough guesstimate to start off with
	//They should definitely be verified experimentally and would almost certainly vary with different resins, baseplates and FEP/nFEP films/coatings

	//Define the raw forces
	// FEP exerts traction on the single voxel it is in direct contact with - whether set or unset.
	//Two stacked voxels must be vertically "glued together" more strongly than the traction the FEP exerts on the voxel - otherwise every voxel would remain attached to the FEP.
	// since a tower would typically break off the baseplate before it broke in half this is typically stronger than FEP but weaker than inter-voxel binding force
	float FEPTractionForce = 5;
	float voxelBindingForce = -10;
	float basePlateBindingForce = 7.5;
	float minimumBasePlateCureLevel = 0.5;    // cure levels below this will not adhere to the baseplate
	float maximalForceReductionByLayerSlowing = -3;     // what is the sensible limit of force reduction which can be achieved by slowing the layer retraction? 
	
	const float uncuredVoxelForceTransmission = 0.01;   // Even an uncured voxel has more force transmission than air 

	// Now define the proportion of force a voxel exchanges with surrounding voxels
	//For initial simplicity it is assumed a given voxel will only cause traction on a voxel in direct contact with it, and that the binding force and traction forces are proportional
	//This is obviously wrong (eg a bridge transmits force along it's full length)
	//This process could be made more accurate by iteratively recalculating (effectively spreading the force over a wider area) until a "minimal change" was achieved, that might be quite computationally intensive, but users could define their own thresholds for this, and potentially have an "complete stage now" option to break out of such a loop...
	// Also assume it will only transmit downward towards the baseplate (this is clearly incorrect but in most cases retrograde forces are not relevant to printing)
	//forceTransmissionMatrix provides a rough approximation of the relative traction that would be exerted on a voxel if all surrounding voxels are present
	//It will be assumed that if a pixel is not present it's proportion of the force will be proportionally divided amongst all remaining pixels
	float forceProportionTransmissionMatrix[] = {
		// current layer
		0.25, 0.5, 0.25,
		0.5, 0, 0.5, // 0 = current voxel (it doesn't exert force on itself)
		0.25, 0.5, 0.25,
		// layer above/below
		0.12, 0.25, 0.12,
		0.25, 0.75, 0.25,
		0.12, 0.25, 0.12,
	};











	//This array contains the maximum traction a given voxel will experience. 
	// The binding force for a given voxel will need to exceed the traction force or that point in the print will fail
	float voxelMaximumTraction[] = { 0, 0, 0 };

	//First calculate the CPFT for each voxel in the entire 3D array and store in a reference array
	float c;
	float CPFTMatrix = CureProportionalForceTransmission(c);

	//start at the baseplate layer then step up to the last layer
	//assign each voxel in the top layer a traction force of FEPTractionForce * CPFTMatrix[voxel]

	//step through every layer below the current top layer
	//calculate the Total Force Transmitted into each voxel by the 8 surrounding voxels in the same layer and the 9 voxels above the current voxel using the FPTM to proportionally assign values for the spread of traction down through the matrix
	//if desired the spread could be repeatedly recalculated using the latest force value until change dropped below a certain threshold to simulate force spread to more distant voxels.

		//when force calculations + / -all iterations finished then compare result against voxelMaximumTraction.
		//if TFT > voxelMaximumTraction[voxel] then update the maximum for that voxel







    // Check greyscale voxels to ensure they will either definitely adhere to the baseplate or will not be exposed to UV at all 
	float halfMinimumBasePlateCureLevel = minimumBasePlateCureLevel/2;
	for (int y = 0; y < rangeY; y++) {
		for (int x = 0; x < rangeX; x++) {
			if (voxelCureLevel[0][y][x] < minimumBasePlateCureLevel) {
			    if (voxelCureLevel[0][y][x] < halfMinimumBasePlateCureLevel) {
			        voxelCureLevel[0][y][x] = 0.0;
			    } else {
			        voxelCureLevel[0][y][x] = minimumBasePlateCureLevel;
			    }
			}
		}
	}

	// assign baseplate binding force to every voxel in contact with the baseplate
	//This is the maximal force it will be able to transfer to the next layer to oppose from FEP traction
	// The general assumption is that the baselayer will always adhere to the baseplate during first layer printing no matter the voxel cure level. 
	// I don't think that's true, but it is likely a binary threshold (ie one which is determined for an individual voxel without much influence from the voxels)
	// The the entire force is directed along the Z axis and not currently influenced by surrounding voxels 

	// insert the baseplate force for each voxel in layer 0
	for (int y = 0; y < rangeY; y++) {
		for (int x = 0; x < rangeX; x++) {
			voxelSupport[0][y][x] = basePlateBindingForce * CureProportionalForceTransmission(voxelCureLevel[0][y][x]);
			voxelForceVectorXYZ[0][y][x][X] = 0;
			voxelForceVectorXYZ[0][y][x][Y] = 0;
			voxelForceVectorXYZ[0][y][x][Z] = basePlateBindingForce;
		}
	}

    // repeatedly step up the layers increasing the maximal layer (zTop) each time 
	for (int zTop = 0; zTop < rangeZ; zTop++) {
	    
    	// add in the FEP traction force to the top printed layer
    	for (int y = 0; y < rangeY; y++) {
    		for (int x = 0; x < rangeX; x++) {
    			voxelSupport[0][y][x] = basePlateBindingForce * CureProportionalForceTransmission(voxelCureLevel[0][y][x]);
    			voxelForceVectorXYZ[zTop][y][x][X] = 0;
    			voxelForceVectorXYZ[zTop][y][x][Y] = 0;
    			voxelForceVectorXYZ[zTop][y][x][Z] = basePlateBindingForce + FEPTractionForce;
    		}
    	}
    
    	// TODO: repeat the loops for the edges (array bounds will be exceeded  from this main loop - but we definitely don't want to have to do excessive logic checks here)
    
        int z=0;
    	// calculate the influence of neighboring voxels on the force vector
    	// Store this in a temp array until impact of all neighbors is complete
    	for (int y = 1; y < rangeY-1; y++) {
    		for (int x = 1; x < rangeX-1; x++) {
    
                //TODO:  Consider the influence of voxelCureLevel   * CureProportionalForceTransmission(voxelCureLevel[0][y][x])
                //This is likely to be much faster to do by precalculating a lookup map 
    
                // voxels with attached faces on same layer
    		    voxelForceVectorXYZtmp[z][y][x][X] -= voxelForceVectorXYZ[z][y][x-1][Z];
    		    voxelForceVectorXYZtmp[z][y][x][X] += voxelForceVectorXYZ[z][y][x+1][Z];
    		    voxelForceVectorXYZtmp[z][y][x][Y] -= voxelForceVectorXYZ[z][y-1][x][Z];
    		    voxelForceVectorXYZtmp[z][y][x][Y] += voxelForceVectorXYZ[z][y+1][x][Z];
    
                // voxels at diagonal on same layer
    		    voxelForceVectorXYZtmp[z][y][x][X] -= voxelForceVectorXYZ[z][y-1][x-1][Z]*0.1;
    		    voxelForceVectorXYZtmp[z][y][x][X] += voxelForceVectorXYZ[z][y-1][x+1][Z]*0.1;
    		    voxelForceVectorXYZtmp[z][y][x][Y] -= voxelForceVectorXYZ[z][y+1][x-1][Z]*0.1;
    		    voxelForceVectorXYZtmp[z][y][x][Y] += voxelForceVectorXYZ[z][y+1][x+1][Z]*0.1;
    
                // the voxel directly under current voxel
    		    voxelForceVectorXYZtmp[z][y][x][X] -= voxelForceVectorXYZ[z-1][y][x][Z];
    
                // voxels with attached faces on lower layer
    		    voxelForceVectorXYZtmp[z][y][x][X] -= voxelForceVectorXYZ[z-1][y][x-1][Z]*0.1;
    		    voxelForceVectorXYZtmp[z][y][x][X] += voxelForceVectorXYZ[z-1][y][x+1][Z]*0.1;
    		    voxelForceVectorXYZtmp[z][y][x][Y] -= voxelForceVectorXYZ[z-1][y-1][x][Z]*0.1;
    		    voxelForceVectorXYZtmp[z][y][x][Y] += voxelForceVectorXYZ[z-1][y+1][x][Z]*0.1;
                // same voxels' influence on the z component of the index voxel
    		    voxelForceVectorXYZtmp[z][y][x][Z] -= voxelForceVectorXYZ[z-1][y][x-1][Z]*0.15;
    		    voxelForceVectorXYZtmp[z][y][x][Z] -= voxelForceVectorXYZ[z-1][y][x+1][Z]*0.15;
    		    voxelForceVectorXYZtmp[z][y][x][Z] -= voxelForceVectorXYZ[z-1][y-1][x][Z]*0.15;
    		    voxelForceVectorXYZtmp[z][y][x][Z] -= voxelForceVectorXYZ[z-1][y+1][x][Z]*0.15;
    
                // voxels at diagonal on lower layer
                //(probably too small an impact to be worth including)
    		    //voxelForceVectorXYZtmp[z][y][x][X] -= voxelForceVectorXYZ[z-1][y-1][x-1][Z]*0.01;
    		    //voxelForceVectorXYZtmp[z][y][x][X] += voxelForceVectorXYZ[z-1][y-1][x+1][Z]*0.01;
    		    //voxelForceVectorXYZtmp[z][y][x][Y] -= voxelForceVectorXYZ[z-1][y+1][x-1][Z]*0.01;
    		    //voxelForceVectorXYZtmp[z][y][x][Y] += voxelForceVectorXYZ[z-1][y+1][x+1][Z]*0.01;
    
    		}
    	}
    	
    	
    	// now calculate the change in voxel force vector after accounting for external influences 
    	for (int y = 0; y < rangeY; y++) {
    		for (int x = 0; x < rangeX; x++) {

                // voxels with attached faces on same layer
    		    voxelForceVectorXYZ[z][y][x][X] += voxelForceVectorXYZtmp[z][y][x][X];
    		    voxelForceVectorXYZ[z][y][x][Y] += voxelForceVectorXYZtmp[z][y][x][Y];
    		    voxelForceVectorXYZ[z][y][x][Z] += voxelForceVectorXYZtmp[z][y][x][Z];

    		}
    	}
    	

    	// now search for voxels where the z force vector is +ve - these voxels need additional support
    	// add them to the list of voxels needing support and the maximal support required
    	// support strategy will be chosen later

    	for (int y = 0; y < rangeY; y++) {
    		for (int x = 0; x < rangeX; x++) {

    		    voxelForceVectorXYZ[z][y][x][Z] += voxelForceVectorXYZtmp[z][y][x][Z];

    		}
    	}

// TODO: once the active print face is more than (eg) 10 layers beyond a given layer then the forces should stabilise. At that point it should be possible to treat larger blocks of voxels as a single unit. These could be progressively averaged - eg a 10x10x10 cubes would decrease computation by a factor of 1000, but if each new stable layer could be added to such block then potentially there would be only limited computational impact of increasing model size as only surface layers would need to be iterated over.
    	
	}

    // The output of the above processing is a list of unsupported voxels 
     // At this point the support strategy can be chosen
	//if the force requirement is less than can be achieved by slowing the model retraction for that layer then use this strategy by default
	// it is likely that each individual support will cost a human around 1 minute to cleanly remove - therefore slowing the print
	// causes both less damage to the print and likely saves more time for the user.
	// an exception will be where a large number of layers are slowed when a single support might have prevented a significant time delay.
	
	// those voxels needing physical supports are then ordered by proximity
	// The automatic system should be able to select from a range of supports which could include 
	//     an i-beam (vertical or otherwise), 
	//     a zig-zag wall
	//     a weakly bound "second skin" reaching from nearby on the model
	//     traditional solid cylindrical sprues with conical tips


	// print buildvolume and voxelsupport to the console
	for (int z = 0; z < rangeZ; z++) {
		std::cout << z << std::endl;
		for (int y = 0; y < rangeY; y++) {
			for (int x = 0; x < rangeX; x++) {
				std::cout << buildvolume[z][y][x];
			}
			std::cout << "    ";
			for (int x = 0; x < rangeX; x++) {
				std::cout << voxelsupport[z][y][x];
			}
			std::cout << std::endl;
		}
		std::cout << std::endl;
	}

	getchar();
	return 0;


}
 

[dgm3333]

After writing a lot of code and getting to the point of being about to to reverse engineer the underlying mesh I finally agree with you - stress analysing the underlying mesh is going to be MUCH faster.
I've therefore forked the blender 3d-printing toolbox which provides similar tools to UVTool but working directly the mesh pre slicing and I will work on that instead (https://github.com/dgm3333/3d-print-toolbox-modified).
If that works it will probably be worth just adding a direct file export to SLA/DLP format from Blender and cut out the middle pieces of software, so I'm unlikely to work on this any more.

[sn4k3]

You need to optimize the code, it must do in parallel or it will take ages.
Resin trap computation is indeed reconstructing the 3D model of hollow spaces, it look at contours and intersect them with upper and lower layers, still i do the comapre in sync so its a bit slower too, i need to find a proper optimization there, if you want to have a look: https://github.com/sn4k3/UVtools/blob/master/UVtools.Core/Layer/LayerManager.cs#L1301
Some day i will try to rebuild the 3D information from 2D in a tree so we can have access to a lot more information and keep model as an vector.

[X3msnake]

i looked for the toolbox you mention but all i see is just a tool to fix meshes what am i missing? what do you mean provided similar tools to UVTools at mesh level? No dia quarta-feira, 7 de abril de 2021, dgm3333 ***@***.***> escreveu:

…

After writing a lot of code and getting to the point of being about to to reverse engineer the underlying mesh I finally agree with you - stress analysing the underlying mesh is going to be MUCH faster. I've therefore forked the blender 3d-printing toolbox which provides similar tools to UVTool but working directly the mesh pre slicing and I will work on that instead. If that works it will probably be worth just adding a direct file export to SLA/DLP format from Blender and cut out the middle pieces of software, so I'm unlikely to work on this any more. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#176 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACUR56UTFSWZRWKQE2CCJMDTHQWWNANCNFSM42FUIKWA> .

-- Com os melhores cumprimentos, Vinicius Silva

[dgm3333]

Sorry I didn't mean to imply the Blender addon was anything like the sophistication of UVTools, just that it provides direct access to meshes, and can resolve problems before the slice even starts. Thus as a result it probably also makes more sense to work with for stress analysis, support creation, and then directly slicing to pass to UVTools (although I've only briefly looked at your code for creating a CTB file for the grayscale export to UVTools). Admittely if I was really going to do stress analysis properly I'd probably use FreeCAD as it has builtin system for doing exactly that and is far better than Blender in that respect, but since both use Python for scripting it isn't too difficult to switch).