#3.2 Interace
9 messages in this thread
>>Imagine 3.2 has been said to allow user defineable screen sizes for the
editors as well as 256 colors.<<
GreG, or whomever,
I just found this little tidbit in one of the previous threads. Do you think
this will slow down screen redraws at all? Do you think Impluse'll put the
options for # of colors, and screen size in Preferences so it's user
defineable? I want more colors and adjustable resolution for the interface, but
I'm concerned about a loss in responsiveness. That's what I've come to love
most about using Imagine on the P5.
Tim
>>Do you think this will slow down screen redraws at all?
Tim,
The added overhead for the increased screen size and 8 bitplanes does slow down
screen redraws, especially if you don't have a super duper high end graphics
card.
>>
Do you think Impluse'll put the options for # of colors, and screen size in
Preferences so it's user defineable?
<<
From what I understand the settings for screen resolution will be defined in
Preferences. So you can always have the 640×480 4bit interface if speed is a
concern.
-GreG
>>3.2 *INTERACE*<< I guess that qualifies as a “newbie''.
Either that, or it's a Freudian slip, and I've got a bad case of Jungle Fever.
GreG,
One more question that 's been nagging me about 3.2. Have you heard whether
Impulse fixed the bug in Altitude Mapping.
When I MORPH or use BONES to deform an object with a LOCKED Altitude Map, the
pattern stretches with the surface, but it starts to get EXTREMELY dark pits.
This happens in both 3.0 and 3.1. I suspect the problem has something to do
with the shading algorithm and the Y-axis that defines bump depth, because the
problem does not occur with regular Color Maps, they strech and bend with the
surface nicely.
I dropped Impulse a line about a week ago, and they said others had reported a
similar problem, but I've seen no mention of it in any of threads going as far
back as 9/94. I guess noone else on the forum has tried to morph an object with
an Altitude Map yet.
I wouldn't be bugging you about this, except that it's a fairly critical
problem in some of the animation I want to do. Boned objects like Dinosaurs are
just more convincing with TACKED bumpy textures.
Tim
Tim,
I know the bug you are referring to, and it seems to affect altitude maps when
they are only locked to a state. Impulse is aware of it, though I don't know
whether it's fixed for 3.2 yet. It is something that NEEDS to be fixed for
states to be even more usefull.
-GreG
In addition, I hope they fixed another Altitude Mapping bug: the one-pixel
border which appears when you use repeating maps. Makes creating repeating
patterns, like leather for example, impossible, unless you want a "leather
bathroom tiles" effect.
Blaq!
>> I hope they fixed another Altitude Mapping bug: the one-pixel
border which appears when you use repeating maps.<<
Me too, Charles. This one's been around for quite awhile.
But at least I found some work-arounds for this, in case anyone needs them. For
a flat surface, you can tile maps together in an image processor BEFORE
applying them, and not use Repeat.
But this won't fix the seam on Cylindrical or Spherical maps. So here's a nasty
work-around for that. Create a Front and Back Hemisphere for your object using
Subgroups. Take the bump map into an image processor like ADPro, and ROLL the
seam so its in the middle of the image. Apply the original bump image to the
Front Hemisphere Subgroup, apply the rolled image (with the Brush axis also
rotated 180 degrees in Z) to the Back Hemisphere Subgroup. This way you hide
the seams of both images in a part of the object where they aren't visible. The
bump maps (excuse me, Altitude maps) apparently make a smooth transition across
Subgroup boundaries.
<retching sound> But it works.
Altitude maps are the biggest memory hogs though, and for users, especially
with low memory environments, there needs to be a better solution. For the
other problem I mentioned earlier, about bump (sorry, Altitude) maps going
haywire when locked to a morphed object, there IS NO workaround that I can see.
Tim
Blaq
The altitude problem while a real pain in the arse, is not a bug, we
have know about it from the point at which we put Altitude mapping in the
software, the problem is this, in order to gain some form of level ground,
there is a one pixel or larger area around the image with the color 128,128,128
or netural gray, This according to the programmers, gives the ability to do
altitude mapping, because we use this color as a middle reference for setting
the bumps or altitudes. I like you agree that it is not what I want, but I
would like to state, firmly, that this is not a bug, we know about and it was
made that way, so I guess you could say its a design flaw, one we are working
on in order to fix it, however we are stumped and are looking for some,
resonable way of fixing it without the process of re-writing the rendering
engine, which would take far too long. I will keep you posted.
Mike
Mike,
I understand the need to establish a 1-pixel border around the altitude
map. After all, I assume the normal disturbance at any point is calculated
by conputing the difference between that point's brushmap pixel, and the
pixels above and to the left; this means the top row and left column of
the brushmap need fake neighbors.
But why oh why has Scott decided to initialize that 1-pixel border with
128 values? Why not simply wrap around and initialize the border with
pixel values from the other side of the brushmap?
What Imagine seems to do:
Assign storage for altitude map + border:
=== === === === === ===
=== — — — — ===
=== — — — — === (— = brushmap, === = 1-pixel border)
=== — — — — ===
=== — — — — ===
=== === === === === ===
Assign initial values (I created some hypothetical brushmap values)
128 128 128 128 128 128
128 1 2 5 4 128
128 11 22 55 44 128
128 111 122 155 144 128
128 211 222 255 244 128
128 128 128 128 128 128
Using my idea, the matrix would look like this:
244 211 222 255 244 211
4 1 2 5 4 1
44 11 22 55 44 11
144 111 122 155 144 111
244 211 222 255 244 211
4 1 2 5 4 1
Why don't you run that idea by Scott and see if it's compatible with that
actual altitude mapping algorithm? Would this result in a seamless
repeating map?
Blaq!