I recently worked on max scenes created by another person and now, whenever I pan or circle the camera the model switches from being rendered to showing bounding boxes. As soon as I stop moving, it switches back again. It's really annoying. I've never used that function before, so I don't know how to turn it back to normal. Anyone know? TIA.
Edit: Found it. Toggle it by Views > Adaptive Degredation or hitting the O key. I was mucking about in the Viewport Configuration the whole time, which stupidly enough has a tab called "Adaptive Degredation" but no box to tick it on and off.
I happen to be experiencing a new annoying problem
I like making tilesets, which naturally requires extreme precision to avoid glitches. I create my model, in most cases from splines, and everything goes well... until it's time to position the vertices exactly.
Some that are supposed to be at 128,0 are. Others are at for instance 127,9999923706 while others may be at 128,0000004321. If I enter 128,0 in the coordinate box and hit return it switches to the other faulty value, and I can enter the right coordinate for ages while it still switches back and forth from just above or just below 128,0. Does anyone have a solid tip on how to ensure that vertices get positioned at exactly the number I enter all the time?
hahaha, hate that! thats not a new one to me
. its weird but sometimes I can't change a verts position by .001. but its usulally fine for whole rounf#d numbers such as 128. and jesus! how do you have some many decimal places?
Unless someone else knows proper way to sort it. like some option in snaps and grid that deals with that... like sensitivity or something :S. I'll do some stupid workaround. make planer, or something annoying involving a new face, target weld or some maddness.
NOTE: Not a solid tip, but maybe something. Maybe.
Well, I saw that before once. I accidentally - can't remember what I was doing at the time - opened an OBJ file (Wavefront format?) in Notepad. The interesting thing I saw after realizing it wasn't what I was looking for was that it was an OBJ file and those lines with "v" at the beginning were vertex coordinate lines, X, Y, Z. It isn't just in Max, it exists in Blender too because that was an OBJ I exported from Blender.
I did a little experiment just now.
I took one of my OBJ files in Notepad, rounded off the values, and imported it into Blender. The mesh looked just fine but I couldn't see what the exact coordinates were (Blender displays it at three decimals), so I exported it again to see if the process would reset any values. When I opened the new exported file in notepad, the values were exactly what I set them to earlier. Perhaps this method could be used for Max? I've only tested it in Blender with a Wavefront exporter.
It would be a little more complicated for meshes with a lot of vertices (getting into 1000's), though. But if someone were to create a program that rounded all the vertex coordinates (lines starting with "v ") to a number of decimal places specified by the user (maybe 4?), I imagine that would make things simpler.
I attached text file versions of my OBJ files. There is no UV mapping, just the basics.
I didn't look yet, but maybe there's a program out there that already does what I described?
So, hopefully something helpful will come of this. If not, oh well. I tried
Glad I'm not the only one, hehe
Thanks for the info TID. Sounds awfully complicated though. You can open up a nif in Nifskope, unroll a NiTriStrips block of your choice, and select the NiTriStripsData block. Then in the Block Details window, unroll the entry called Vertices. From there you can manipulate the position of every vertice.
Well Ghogiel the reason I decided to go with so many decimals is that previously I used only two decimals and I noticed that even if the vertice was said to be at "128,00" I still saw a seam between it and the adjoining vertice. That made me think that the vertices must be positioned wrongly, but because I had too few decimals display, the program just rounded it off to "128,00".
What's your thoughts on that? Because lately I've discovered something new relating to tileset modelling that I've been completely oblivious to before;
the faces have to meet up perfectly on both sides else there will be visible tears - whether the vertices are exactly at "128,0" or not. (Or you can bleed one side into the other but that's not ideal when working with for instance border textures) So you can't have three faces on one side meeting up with one face on the other side, even if the vertices are where they need to be to prevent seams. Doing that causes a miniscule but highly visible seam, presumably by something in the Oblivion engine.
I think it took so long for me to figure out this effect because I tend to start work on a tileset by creating a connecting side and then mirroring it, so right from the get-go the bulk of the seams will match perfectly.
So lately I've begun thinking if the seam I thought was caused by too few decimals was actually caused by faces not lining up on both sides.
Not sure what you mean. How can 3 faces meet 1 face but have the same maticing vertices on each side. The game engine will break smoothing and cause an strange lighting along the seam of adjacent tiles if the verts aren't occupying the same space, or there are extra verts on one nif that aren't matched on the other nif.
I actually ran into this again not be able to set a rotation .001. I figured 2 things. It worked if I deleted everything else from the scene. And it also worked if I modified in this order, ZYX. But not any imputs I tried. weird.
I was setting about 10 different helmets pivot translation and rotation to the head bone for egms. But came across the wierd bug.
Quote:Originally posted by Ghogiel
Not sure what you mean. How can 3 faces meet 1 face but have the same maticing vertices on each side. The game engine will break smoothing and cause an strange lighting along the seam of adjacent tiles if the verts aren't occupying the same space, or there are extra verts on one nif that aren't matched on the other nif.
I meant that there'd be seams if one side has three faces and the side that meets up with it has one face even if the vertices are positioned so that there
shouldn't logically be any seams, i.e. the vertices on both sides only differ on one axis. I'm not saying you didn't know that, but rather that I didn't know that until fairly recently.
ah. that'll cause a seam. It will break the smoothing if the verts don't occupy the same space. Phitt was doing that a little while ago and wondered why it was causeing a seam, to me it looked like the mirrored UVs or adjacent faces sharing the same UV co-ords. (which is annoying as hell, and knowing what it looks like have found many Beth meshes that have it. ) but Phitts issue was vertices along an edge that broke smoothing.