Anim8or Community

Please login or register.

Login with username, password and session length
Advanced search  


Ian Ross has just released a book on Anim8or. It's perect for a beginner and a good reference for experienced users. It contains detailed chapters on every aspect, with many examples. Get your own copy here: "Anim8or Tutorial Book"

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - cooldude234

Pages: [1] 2 3 ... 61
Finished Works and Works in Progress / Re: Redesining my first protagonist
« on: February 06, 2018, 01:14:36 am »
Wouldn't be surprised if you got a job in the industry with all these renders under your belt ;P

General Anim8or Forum / Re: Coding Anim8or
« on: May 17, 2017, 06:18:20 pm »
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

Anim8or Challenges / Re: Challenge #34: Anim8or 1.0 splash screen
« on: April 24, 2017, 09:40:35 pm »
I might have to get in on this...

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

General Anim8or Forum / Re: Grid Changes?
« on: October 01, 2016, 09:20:06 pm »
Thanks Steve!

I just tested this out and it sort of works like I wanted it to but not quite.
So I think I know of a potential fix for this.

My main use case example is like this; you have a cylinder that faces vertically (for this example lets say the ends of the cylinder are have way between the grid 0.5), I want the ends of the cylinder to match the grid but only in the y direction . So in that way they points could snap to the grid instead of just moving 1.0+ from their previous position.
Right now if I take my cylinder with its ends being between where they should snap, and move them up by one with the grid enabled they will still be inbetween where they should snap.
My suggestion is to make it so if you hold down a different key (like ctrl) and move, it snaps the points ONLY by the axis you have selected and the other axis remain the same.

EG I have my cylinder and I want to snap the ends of it to a grid of 1.0 intervals and they currently are sitting at 0.4 between the grid. I enable the Y axis to move only and I hold down ctrl while moving the points and all the points snap to the 1.0 grid BUT ONLY on the Y axis.

PS. Sorry if the post is hard to read, I'm a bit sleepy right now ;p

General Anim8or Forum / Grid Changes?
« on: September 30, 2016, 04:43:29 pm »
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.

Build 1250 marks a version bump: Anim8or is now 0.98b =)
Steve, a small feature request, if I may:
I had mentioned a feature request like this little while ago, however this video is a great visual demonstration and hopefully gets implimented.

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 :P).

Okay, well Unicode is working perfectly fine now. Once font rendering is redone, you will be able to have any character from any language available to use at any point in realtime.

I'm just not too sure how non us standards will far with certain things (though in theory they will still be able to type native characters in correctly).

Working on something ya'll might like ;)

General Anim8or Forum / Re: render resolution question
« on: August 02, 2016, 06:11:01 pm »
I wrestled with a lot of codecs early on trying to get one that wouldn't glitch out or get massacred in the Youtube compression.

As someone who deals with codecs on almost a daily basis, I can tell you they're a pain in the rear and extremely difficult to get working correctly in the way you want; even for an advanced user. So don't feel bad if you are having troubles with them :P

Also Xvid codec works extremely well at higher resolutions (4k and beyond), but it just gets way to taxing on CPU resources to decode all that wonderfully compressed data in real-time. IE quality vs size is superb but performance is meh.
So I really like it as an archival compression method.

General Anim8or Forum / Re: render resolution question
« on: August 01, 2016, 01:30:44 am »
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.

General Anim8or Forum / Re: render resolution question
« on: July 31, 2016, 02:59:04 am »
It would be great if Animator saves images in 300ppi by default, that way the quality of rendered pictures be perfect.

Youtube seems to be making some readjustments after I upload video rendered within Anim8or which looks crystal clear on computer, but it always lose a lot of quality in YT. That never happens when I render animation in png pictures and connect those pictures into video with some other program. Maybe that's also related to unusual ppi values. 

Nah that would probably be something entirely different. The problem you are probably encountering has to do with codecs. That and you-tube compresses everything down to crap.
It took me a while to get you-tube to accept my 4k 60fps recordings and even then it still looks like garbage compared to the lossless original (but mind you the original did take 10 gigs just for a minute of video :P)
Shameless plug here

General Anim8or Forum / Re: render resolution question
« on: July 30, 2016, 04:35:39 am »
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).

General Anim8or Forum / Re: render resolution question
« on: July 29, 2016, 03:12:53 am »
To be honest depending on the printer (the people doing the printing not the machines themselves) you can usually just state what dpi your image is in and send them the image data in a format they accept and they usually will be fine with that. And printing for something like a comic book can get pretty complicated with having to deal with things like bleed margins and stuff. But it really depends on who's doing the printing because there are many different ways to go about it and some companies will only except certain things.
My best advice is ask if they want the dpi included inside the image file.

Pages: [1] 2 3 ... 61