Also http://www.weplayciv.com/forums/showthread.php?6789-HOW-TO-SMACX-caviar-files-listed (http://www.weplayciv.com/forums/showthread.php?6789-HOW-TO-SMACX-caviar-files-listed) has a handy list of the cvr files.
I'm not sure how possible this is, but maybe a preview box? there might be a python script somewhere to re-wrap the textures in a separate window to let you preview how your unit/pieces will look without needing to load the game.
Another nice feature would be saving onto the current file instead of saving a new one or overwriting a previous version.
I'd also like to suggest maybe increasing the level of zoom. Unless I'm doing something wrong I think it only has one zoom size currently. usually when working on stuff like this I zoom in super close to do detail work.
Though doesn't the program already mirror in a way (which has been REALLY nice), or is there something more you want to do with this?
Importing an image - Possible. It wouldn't be too hard to just spray the image on, the problem is that it would only look right on flat surfaces. Doing only that would be fairly easy, but limited in its usefulness. To get it to apply an image onto a sloped surface and look good would be hard. I would like to hear opinions on whether or not the limited pasting of an image would be worth it or not.Assume I have no experience of 3D modeling and therefore have trouble following the tech talk.
Assume I have no experience of 3D modeling and therefore I have trouble following the tech talk.
* You can save your changes again!Such a good feature!
But heres a thought. Tiberian Sun already has a well made and excellent Voxel edtior. All we need to do is figure out how to convert a cvr to a vxl format.
... Eureka! A tiny colony pod w/ purple tank for the .cvr modder badge!
Yes?
BTW, let me know when you're ready for publicity, and we'll put our heads together and I can promote the heck outta yer .cvr editor the way Yitzi's patch is getting a push right now. It's good for AC2, and it's good for getting your mod into maximum user hands. ;b;I'm sorry I haven't gotten up with you on this three days ago, Ford, but Beyond Earth happened, I've been way too busy to get to everything that needed getting, and it just would have gotten drowned out anyway. We should be conducting the interview anyway, in preparation for the right time, as doing it via post will take a while. I really ought to be doing this with kyrub, too.
How did you first take an interest in this project.I wanted to try to make a smac clone. So I googled around and found out no one knew how to read the calviar format(.cvr). So I figured, what the heck... I'll give it a try.
Is this indicating a current lack of interest in promoting it? I'd point out that promoting would tend to help bring in those people who might make the breakthroughs you hope for.
Why the .cvr part in particular, though?It was the only major graphics component that no one could read. I could use any of the other images for the terrain, faces, gui, etc, but the actual units were in the cvr file format. I thought it would be quicker and easier to figure out the .cvr format than it would be to recreate the units from scratch in blender. (I was wrong. :D )
What can be done with your .cvr editor?
Could I turn the colony pod into a covered wagon with it?
What do you think can be done in the future, assuming some breakthroughs?
Okay, define normal for non-tech types to whom that last would make no sense.
What do you want people to know about the project?
Do you think we're getting anywhere near covering things adequately for an article?Probably. I can't really think of anything more to say.
>Hi again!
>There is this article about Animatek's new Caviar Technology in one issue
>of Game Developer.
>It's supposed to be some system that renders truly 3D pixel characters in
>realtime.
>It sounds a bit like voxels to me, but it's much faster.
>The demo they have on the Animatek website looked pretty impressive.
>Does anyone have any idea how it is done?i
I suppose, they store all voxels of the
surface in a array that looks something
like this:
struct Voxel {
char Color;
char nextVoxel;
Normal normal;
};
Voxel Surface[NumVoxels];
'nextVoxel' describes the relative position
of this voxel to the previous voxel. If
subsequent voxels are always neighboured, there
are only 26 possible values for nextVoxel
(i.e. nextVoxel ranges from 0 to 25).
To render a parallel projected surface, you
first create for each position of the viewer
an array that contains the values for the
relative positions of the neighboured voxels
in _screen_ coordinates:
Vector relVoxelPosition[26];
Now, compute the screen position of the first
voxel, and you can compute the positions
of the subsequent voxel using only additions.
At each Voxel, compute the intensity using
the stored surface normal, and draw it as
a single pixel (or as a square of pixels).
Maybe it is a good idea, to render the
surface always at a constant size, and
sample it down before drawing it on the
screen.
Hidden Surface removal can be done either with
a z-Buffer, or by subdividing the surface into
smaller pieces, that are rendered back to front.
I suppose, this method should be fast enough
for realtime rendering, since it contains no
expensive operations (about four times
more expensive than bumpmapping).
Did you come across http://www.graphicsgroups.com/5-graphics-algorithms/cf6d650baaf8850c.htm (http://www.graphicsgroups.com/5-graphics-algorithms/cf6d650baaf8850c.htm)
(rather like making a clay model by rolling a 'snake' and then winding it back and forth to build up a form, the metaphor is also apt to the "normal" process that visually 'smooths' the voxels into a surface for display).
You can think of this as something like a mummy: the original polygonal model serves as the mummy’s body, which is then completely wrapped in a strand of 3D pixels — thereafter, only this wrapping is used to represent the character.