Maya Zero

[Faustina Bartsch]

The Mayan numeral system was the system to represent numbers and calendar dates in the Maya civilization. It was a vigesimal (base-20) positional numeral system. The numerals are made up of three symbols: zero (a shell),[citation needed] one (a dot) and five (a bar). For example, thirteen is written as three dots in a horizontal row above two horizontal bars; sometimes it is also written as three vertical dots to the left of two vertical bars. With these three symbols, each of the twenty vigesimal digits could be written.

Other than the bar and dot notation, Maya numerals were sometimes illustrated by face type glyphs or pictures. The face glyph for a number represents the deity associated with the number. These face number glyphs were rarely used, and are mostly seen on some of the most elaborate monumental carvings.

There are different representations of zero in the Dresden Codex, as can be seen at page 43b (which is concerned with the synodic cycle of Mars).[2] It has been suggested that these pointed, oblong "shell" representations are calligraphic variants of the PET logogram, approximately meaning "circular" or "rounded", and perhaps the basis of a derived noun meaning "totality" or "grouping", such that the representations may be an appropriate marker for a number position which has reached its totality.[3]

If five or more dots result from the combination, five dots are removed and replaced by a bar. If four or more bars result, four bars are removed and a dot is added to the next higher row. This also means that the value of 1 bar is 5.

If there are not enough dots in a minuend position, a bar is replaced by five dots. If there are not enough bars, a dot is removed from the next higher minuend symbol in the column and four bars are added to the minuend symbol which is being worked on.

The "Long Count" portion of the Maya calendar uses a variation on the strictly vigesimal numerals to show a Long Count date. In the second position, only the digits up to 17 are used, and the place value of the third position is not 2020 = 400, as would otherwise be expected, but 1820 = 360 so that one dot over two zeros signifies 360. Presumably, this is because 360 is roughly the number of days in a year. (The Maya had however a quite accurate estimation of 365.2422 days for the solar year at least since the early Classic era.)[4] Subsequent positions use all twenty digits and the place values continue as 182020 = 7,200 and 18202020 = 144,000, etc.

Every known example of large numbers in the Maya system uses this 'modified vigesimal' system, with the third position representing multiples of 1820. It is reasonable to assume, but not proven by any evidence, that the normal system in use was a pure base-20 system.[5]

Several Mesoamerican cultures used similar numerals and base-twenty systems and the Mesoamerican Long Count calendar requiring the use of zero as a place-holder. The earliest long count date (on Stela 2 at Chiappa de Corzo, Chiapas) is from 36 BC.[6]

I'm fairly new to Maya, and have been trying to keep all models that I create be as clean as possible, but the extrude tool seems to be consistently giving me issues with creating areas with zero map area anytime that I preform an extrusion. Is there any way to avoid this? Manually fixing by using the append to polygon tool works, but is laborious. I believe that I simply must be doing something wrong when modelling, but I have no idea what. Here is what my approach has been to date:

hi, add an image please,

maybe when you extrude you hit 2 times, making an hidden extrusion.
try use the vertex face, visualization, hold down right on mesh and choose vertexface.
can you see the lines between the faces?
these are overlapped vertex that make a face with 0 width.
Select all the vertex of the mesh and hit mergevertex witha proper threshold.
this will merge the vertex and delete the hidden face.

cant see your screenshot , where it is?

the uv cant mess up your extrusion. no way.
try reset your extrude setting. open the option menu and hit edit-reset settings.
create a simple plane and try extrude a face,

I am trying to create clean meshes, and I believe (rightly or wrongly) that in order for that to happen, the cleanup tool should not detect any issues. I am currently under the impression that because the extrusions I do are highlighted by the cleanup tool, I am doing something fundamentally wrong, but I don't know what.

With regards to the UV editor, I am not having any issues with it, but when I append to poly the highlighted areas in the screenshot, the resultant faces are entirely separate from the cube UV shell. (see second screenshot) I guess I'll just have to stitch the faces back onto the cube UV shell.

ooooooook man
now thats clear.

Its perfectly normal.
the "clean up" highlights your faces because they have 0 area
if you scroll down the setup, you can see the option.

Dont worry of your uv until you completely done with the model.
they dont have to be costantly perfect, neither have the cleanup be clean all the time.
Usually when you model complex things , you will have to make things that are qualified as "errors".

After the extrusion , try hit the automatic uv mapping.
the command will make a new projection of your uv and they will have all more than 0 area,
so the highligh will not occur. (will occur only if you have the error i shown you before)

Dont count too much on clean-up , for a really big amount of problem he will not detect it.
modelling is an art XD

I have an issue with several object in my scene where the pivots of the objects gets reset to below zero on the vertical axis. This is a screenshot of the problem, I "Reset Transformations" before taking the shot.

The rotor and tyre also have the problem, but the rims don't. I have reset all the tool settings and made sure they are set to world. I have tried baking the pivots and freezing again before resetting. I have also deleted history and tried restarting the program. Googling the problem hasn't come up with any results for the same thing, I tried several different searches.

I did a bit more working on this and after removing the vertical adjustment in the local pivot, it automatically transfer the value to world pivot and vise-versa. Regardsless of which one the value is in, when resetting transformations, it goes to world. How do I zero them both out?

I have this problem with several objects in my scene and have no idea how it happened. I will be exporting these to be used in a game I am modding to try and learn stuff and require the pivot to be at 0,0,0 for it to render correctly.

If you are willing to take a look and see what I have done wrong, it would be greatly appreciated. I am only a novice user with no training so there are probalby many "non ideal" things I have done and some messy aspects of the scene. Hopefully it isn't too bad.

This would make it hard to animate the wheels around their centers while also moving the whole car so you should probably look at some videos like the one I found below to understand how grouping is used in animation.

For the game engine I am using, anything that rotates indepentantly requires a centered pivot, everything else that moves as a group requires a 0,0,0 pivot. Some of them in the scene may have been different from the finished project as I was trying to sort out the issue.

From the code, we see that the workhorse is the polySelectConstraint command.
In cycles, it works veery slowly.
But its advantage is manifested when working with a huge array of data passed once to this command as an argument.

Naturally, translating coordinate values from object space to world space takes some time.
On a large data set, the difference in the time spent on the execution of the function becomes very noticeable.

With all due respect, this is a false assumption.
Obviously, a grid can contain many different vertices that have the same coordinates but do not have common edges.
The edge length is equal to zero if the coordinates of the vertices are the same and these vertices HAVE COMMON EDGES!

I've been trying to animate on Maya 2019. But as soon as I move away from a key frame, the values all get reset into zero. The key is there but without the values that I've given. I'll link a few pictures for reference

I also opened an already animated file of a friend to check. Only their animation works and key values are visible while any key I add just goes back to zero. I've gotten the software reinstalled twice and it happened in the 2018 version too. I have no idea what is going wrong. Please help!

I had this problem too. I had some geometry that had no UV space and was just kinda broken. Even if I selected the faces and tried planar map it just wouldn't take uvs. Deleting this geometry fixed the problem.

Use Mesh Cleanup (with Operation: "Select Matching Polygons" and "Faces with zero map area" enabled, then you see the problems in Viewport and UV Editor. (Even with lowest "Area tolerance" values it will find some "empty" map areas.) Correct this and it will work.

Any insight into a simple way to fix it would be great. It's an ArchVis project using a model exported from Revit, and I don't have time to go through and hand-fix every piece of geometry I'm getting this error on.

The problem is bad UV mapping, it's not directly a problem with geometry. Even if you don't want to change geometry i recommend to edit the UV mapping. If you only want to add a solid color and not a texture just leave it as it is.

What about the UV mapping is causing the issue? Is it the scale of the UVs in the 0 to 1 space compared to the Map Size specified in the Texel Density menu? If I'm reading the error message correctly, it's having a problem when the area of a UV face is under 1 pixel. Therefore, shouldn't increasing the Map Size eliminate that issue?

Gotcha. We mostly use tiling textures that are repeated sometimes several hundred times to get the detail we need, so it's not an issue for us if the UVs are extremely small. I can see how it would be a bigger problem if you were using a 1:1 texture though. A little annoying that the designers overlooked this particular use-case, but I'll see if I can figure out a work around.

c80f0f1006