You mean American not German I've never seen an M3 with a weapon like that before, looks like a modern MBT turret was just stuck on the back!? _________________
ooops, made an error. Yes, it is an USMC HalfTrack. And yes it has a bigger turret and gun. They normaly had 75mm cannons and a smaller turret, but I was like what the hell, lets give this thing some Kaboom!!!!!
I'm running it thru 3ds2vxl again right now, rearranged the barrel and turret to look more AA and Artilleryish. _________________
The enemy shall be injected with toxic poison - Venom QUICK_EDIT
Sometimes I do, and sometimes I dont. I think it has to do with the textures I use, that if some of them are way outside the palette colors it screws them up sometimes. Not sure why some of them come out looking like shit, while others look good _________________
The enemy shall be injected with toxic poison - Venom QUICK_EDIT
I set the default voxel dot distance as 0.7 but you put it at 0.65 Did you find that necessary? Like did you see gaps at 0.7 ? Maybe some day I should change that default setting.
Woah! you set the voxelization supersampling level to 200?! That must take hours. Does it make a noticeable difference in the end result to set that so high?
Would you mind telling me what sort of things you needed to touch up? Was it the star and head-lights? QUICK_EDIT
@ViPr, Yeah, using 200 on super sampling takes for ever. Why I set it to such a high level I dont remember. But I was fiddling with the super sampling this morning. It seems that using super sampling is what causes irregularities in the vxl texture. If I untick Super Sampling it draws the vxl texture correctly, using it causes palette and normals errors. It does however make a great vxl smoothing and stuff using it, just gives issues with texture drawing.
No, 0.7 is a good number for VoxelDotDistance, just thought I'd go a little lower with it. I'll attach some pics to show with and without sampling to show what it does. The higher the sampling the worse things get texture wise.
Below, pic 1 is without sampling, textures look good, but vxl dosent.
Pic 2, textures are messed up, vxl looks ok. thats using sampling=25, and it also thru me some errors using it (pic 3) The higher the sampling the worse things get with the texturing errors and stuff.
Imagea1.png
Description:
Filesize:
72.73 KB
Viewed:
9433 Time(s)
Imagea3.png
Description:
Filesize:
113.46 KB
Viewed:
9433 Time(s)
Imagea2.png
Description:
Filesize:
14.32 KB
Viewed:
9433 Time(s)
_________________
The enemy shall be injected with toxic poison - Venom QUICK_EDIT
I'm not sure what is causing this problem. I may have to really study the source code again.
The cyan color on the wheels, is that team color or colors that are not supposed to be used from the color palette? like does the cyan change to another color if you change the team color setting in the voxel viewer?
does setting the voxelization supersampling level to something lower like 10, or changing the color multiplier to 1 reduce the problem? QUICK_EDIT
The cyan color on the wheels are the bottom 8 team colors in the palette. The real dark ones. I dont know why VxlViewer displays them that color, but they arent supposed to be there anyway. Thats what supersampling does.
I'll try using a lower numver than 25 and see what happens as well as change the color multiplier. I'll have my results shortly _________________
The enemy shall be injected with toxic poison - Venom QUICK_EDIT
ok, na, it didnt help anything. I did several different combos of sampling and color multiplier. Here is two samples using the luchs II tank from WOT using Sampling= 5 and multipliers =2 and .8
luchs6_000.gif
Description:
Filesize:
4.49 MB
Viewed:
9404 Time(s)
luchs5_000.gif
Description:
Filesize:
4.87 MB
Viewed:
9404 Time(s)
_________________
The enemy shall be injected with toxic poison - Venom QUICK_EDIT
I dont know why vxl viewer does this to me. It displays the upper 8 just fine, but the bottom 8 always displays cyan. It only does this in vxl viewer, looks fine in everything else.
I think whats happening is 3ds2vxl converts any out of range colors to the bottom half of the team colors. It's not a really big issue, and an easy fix, but it's irritating! _________________
The enemy shall be injected with toxic poison - Venom QUICK_EDIT
First, did you get the normal index error and color index error on this last vxl? I don't know what causes that error and I'm not sure I ever knew what causes it. Maybe I knew and forgot. I'll have to examine my source code again.
About the unwanted team color, I think I know quite well what causes it but there is something about it here which is confusing me. Are you sure it is the darkest 8 team colors and not the very darkest team color all the way down? I've noticed a long time ago that the voxel viewer seems to display all shades of team color as though they are the brightest shade. I don't know if this is still the case. Is it? It looks like it is not. I never knew till now about this cyan problem when the team colors are the darkest 8 shades. Maybe that's a new bug in the voxel viewer. I think it should look fine in the game because the team color there will probably look too dark that it will look black. I don't think it is out of range colors being converted to the darker half of team colors. The cause of unwanted team color is that the artist probably intends for the vxl to be black there but it is actually very very dark pure red. 3ds2vxl will consider any shade of pure red as intended to be team color. If the red amount is not zero but the blue and green amounts are zero then team color will be put there.
I suspect that if you opened the texture in a paint program and desaturated it sufficiently or just changed it to greyscale then the team color would go away completely. If you used the dropper, to tell you what the color is there, over certain areas of the texture that correspond to where the cyan is appearing then you'll probably see that although it may look black, it is actually very dark red. QUICK_EDIT
It was throwing both normals and color index errors like in the pic above
I'll try to desaturate the textures and see what happens. But the only time I get the cyan colors is when i get the normal and color index errors, I Think _________________
The enemy shall be injected with toxic poison - Venom QUICK_EDIT
Ok, all the unwanted team color seems to have gone. However, you were still getting the normal index errors and color index errors, exactly the same as before, weren't you? QUICK_EDIT
For some reason I didnt get it this time around. Maybe desaturating the textures this unit uses solved the problem? _________________
The enemy shall be injected with toxic poison - Venom QUICK_EDIT
hmm that's weird. I thought the unwanted team color problem and the index error problem were two totally unrelated problems. I cannot see the connection at the moment. Maybe I'll figure it out if I study the source code for a while. QUICK_EDIT
Joined: 22 Nov 2010 Location: Iszkaszentgyorgy, Hungary
Posted: Sat Mar 03, 2012 10:16 pm Post subject:
Mig Eater wrote:
Cranium wrote:
The cyan color on the wheels are the bottom 8 team colors in the palette. The real dark ones. I dont know why VxlViewer displays them that color
I use the bottom team colors most of the time & I've never seen that error before o.0
I got used to that. And I never had a PC which DIDN'T have that error. I just switch the remap color to green or blue, those are fine. _________________ "If you didn't get angry and mad and frustrated, that means you don't care about the end result, and are doing something wrong." - Greg Kroah-Hartman
=======================
Past C&C projects: Attacque Supérior (2010-2019); Valiant Shades (2019-2021)
=======================
WeiDU mods: Random Graion Tweaks | Graion's Soundsets
Maintainance: Extra Expanded Enhanced Encounters! | BGEESpawn
Contributions: EE Fixpack | Enhanced Edition Trilogy | DSotSC (Trilogy) | UB_IWD | SotSC & a lot more... QUICK_EDIT
By the way, when I was talking about what I observed in the voxel viewer I just realized I was using HVABuilder as the voxel viewer which is different to the program you are using to view the voxels.
I think I'm going to need you to send me the problematic model with textures because I can't seem to find a model that I have that causes the problems.
UPDATE: actually nevermind, I found a model to test on. QUICK_EDIT
Ok, I've been doing some testing and I think I found at least one of the causes of the normal index error. I remember I actually knew about this cause before but forgot. Anyway, I've noticed sometimes the normal index error occurs by itself and sometimes the color index error appears together with it. When they appear together I'm still totally bewildered what is causing it and I even noticed something else seems to sometimes appear at the same time as well and that is floating voxel cubes that don't seem to belong.
Anyway When the normal index error appears by itself, it seems to, at least in some cases, be caused by opposite facing triangles being too close together so that they occupy the same voxel cube and since they are opposite facing, their normals cancel each other out when averaged together so that the normals in that voxel cube end up being zero. When they are zero it causes a zero divide by zero error when the normal is normalized which makes the resulting data indeterminate which I guess means that when I try to use that data to see which normal stored in the palette it is closest to then my algorithm can't work and doesn't find any normal index to use and so just uses a default one that I set. Hopefully the result isn't noticeable ingame.
Unfortunately I will be away from my computer soon so I will not be able to fix the error until maybe a couple of months from now if I can ever figure out what causes it and what to do to solve it. I hope it doesn't cause too much problem and hopefully we can find a temporary workaround in the meantime. QUICK_EDIT
Also Known As: banshee_revora (Steam) Joined: 15 Aug 2002 Location: Brazil
Posted: Mon Mar 05, 2012 9:31 pm Post subject:
That's pretty much a math problem and your algorithm should work correctly if the user doubles or halves the voxel resolution (I'm not sure which of them. What I know is that the user should reduce the space that a single voxel ocupies in the 'universe'). QUICK_EDIT
Anyway, I think this normal index error is not something that should really be worried about. The problem is when you have things that are one voxel cube thick then which way should the normal point? I guess most of the time, for something like a wing, it should be upwards since we rarely see the underside of the aircraft but what about the tail fin with the rudder? You have to either choose to make it face left or right, and whichever way you choose, it's going to look wrong some of the time because you see each side quite a lot. I think if the width of the aircraft has an odd number of voxel slices then the tail fin could end up being a single voxel cube thick but with an even number I hope it usually ends up being 2 voxel cubes thick. That itself could be considered problematic by some people, but oh well.
It's the color index error that is maybe something that needs to be worried about and I'm still clueless what is causing it. It's a very bizarre bug. At the moment I still don't see the connection with the unwanted team color problem and hopefully they are not connected.
The unwanted team color problem is worse with super sampling turned on because in that new mode I've added a feature which I did not bother to add to the other old mode. The feature was designed to stop some team color blending with non team color to result in non team color. This would make the edges of team color areas stay reddish when the team color was changed. I didn't really need to add this feature to the old mode because the old mode doesn't blend things together; it just overwrites things with other things. I don't really intend for people to use the old mode. I just left it in for bug-testing and I've considered removing it many times because it makes my code very messy. Anyway as I said above, I believe the unwanted team color problem is caused by dark pure red being in the textures when black was probably intended instead. Sufficiently desaturating the textures will de-purify the colors but it could cause that horrible current game console generation look fad mainly started with Gears of War, I believe, where the graphics look pretty much monochrome. QUICK_EDIT
Well you really dont need to desaturate the textures, just blow them up and remove any dark reds that dont belong. Simple as that. That way you wont have to worry about the monochrome look.
Thats why i said before it depended on the textures I used that caused the errors. _________________
The enemy shall be injected with toxic poison - Venom QUICK_EDIT
It can be a tedious task, but if you know what your doing It's pretty cut and dry operation.
But i see were your coming from. The easier for the people the better. _________________
The enemy shall be injected with toxic poison - Venom QUICK_EDIT
You cannot post new topics in this forum You can reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum You cannot attach files in this forum You can download files in this forum
M3GMC
I've never seen an M3 with a weapon like that before, looks like a modern MBT turret was just stuck on the back!?
