Anim8or Community

The second issues is that it's not 64-bit safe. I'm slowly fixing that but I still have code that casts pointers into ints for thinks like call back functions (yes, I knew better, but did it anyway to "save time"!)

LOL, I know that feeling

I'm going through hell at the moment. Be back when I finish strangling satan.

When I go into point edit mode with grid enabled and a bunch of points selected, when I move these points they don't retain their position relative to the other points (they don't move in unison).
I am pretty sure that the grid didn't work like this before?
But either way I would like control over whether the points movie in unison (like if all the points where moving like an object does with grid enabled) or whether they move individuality (each point snaps to the grid).

Take for instance, I have a cylinder and I want to move all the points on one end outwards by 1 unit. Right now if I go into point edit mode and select all the points and move them in the Y axis, they will become 1 unit further out but all the points wont be in a circle anymore. The cylinder will end up having a jagged end.

RE*RE*RE*RE-fixed matrix functions
Now using 100% of my matrices without any errors or problems.
This allows me to use GLSL 4.5 or really any version of it now (and will make Vulkan actually do something now ).

Working on something ya'll might like

but I guess the difference should be only visible on printers and ultra HD monitors.
72ppi is the optimal value which works great for pixel density of average computer monitors. I don't have ultra HD monitor so can't tell the difference, but if someone does I'd like to hear that, just render some image in 4K resolution with anti anti-aliasing and save them in BMP and PNG format for comparison.

Well once again the DPI of an image doesn't matter when your viewing those images on a computer (because you can scale them up or down in real-time). You could set the dpi on the image to be 23408329084 if you wanted to and it would look the same on your computer as long as the output resolution is the same.
Also DPI was term coined for printing, and PPI was a term coined for computer monitors. Both values work pretty much the same but they both refer to something slightly different.

As for the codec I was using. I used Nvidia's hardware encoder/decoder with their hvenc codec through the terrible mp4 container format at 4k 60fps with the quality ratio set to a 100.
Doing the math

3810x2160 at 8 bits per channel at 3 colour channels (which is 24 bits for all channels)
24 x 3810 x 2160 = 197510400 bits per image
197510400  / 8 (convert to bytes)
24688800 / 1000 (convert to kilobytes)
24688.8 / 1000 (convert to mega bytes)
= 24.6888 mega bytes

Now we have 60 of these for each second and we have 60 seconds in a minute so...
60 * 60 = 3600
Multiply how many frames we have by how much each frame is...
24.6888 * 3600 = 88879.68 megabytes
88879.68 / 1024 (converting to gigabytes)
= 86.7965625 Gigabytes

Now of course that would be purely lossless and the Nvenc codec was using a variable bit rate with pbuffers and more so if nothing changed in the image in any part it wouldn't have the need to update it so it wouldn't store data for it. On top of that it still was slightly compressing it as a whole. So a 10 gig file over a 86 gig one is still pretty good.
The only codec I've seen come close to quality and space was with the xvid codec where with the same settings I could make that a 2 gig file (but its really process intensive where as Nvenc isn't nearly as intensive).

Trust me, when you are dealing with high quality video expect to deal with the file size that comes with it. I mean if you think about it most bluray movies are about 40 gigs in size and that's at only 1080 at 30 frames a second.

To my way of thinking (with minimal print experience) there's two ways to define the resolution of an image:

1) Specifying the size of the image (in mm or inches) and specifying a DPI resolution; or
2) Specifying the number of pixels in the X and Y dimensions.

The DPI figure is of no value if referring to the image by it's X/Y pixels, it will be determined by the printed/displayed size of the image (ie. DPI = X/W where X is the width of the image in pixels and W is the width in inches).  Conversely, a printer requesting a certain DPI makes sense only if the printed size of the image is known, so if you need a 5 X 8 printed image and the printer needs 300DPI you'd need to render an image 1500 x 2400px.  Or am I missing something?

DPI and resolution are two separate things all together. You can have any resolution and any DPI to get the actual width and height of the final image, or you can have any resolution and any size (eg 11 x 8.5 inch) to get the dpi.
I'm pretty sure what the op's concern is the encoded number (the meta data) within the image file its self. Which as I know not every printer uses meta data (they ask you when making a print request to state the dpi).
I may be wrong but I feel like the concern is more of an inconvenience rather than a problem (since you can easily edit meta data with many different types of software).