Bitmap free workflow?

[Rodney]

I'm staring at a dilemma that seems to resolve around the necessity of including bitmaps (for decals, backgrounds, etc.) and am actively searching for a solution to set aside or exclude bitmaps from the general workflow. Now, this isn't to suggest that bitmaps would not be a part of the project workflow at all but rather to set them aside for a time to optimize the given workflow.

 

As an example, let's say we have a system where the use of only text files is the norm and is preferred.

Let us also assume that text-based image formats (SVG and base-32/base-64,etc.*) aren't ideal either although additional development might allow for them, especially the latter as they are already being used to an extent in the text files (as tiny little icons). **

 

Additional Considerations

Similar to the above form of embedded Bitmap there is also that form of bitmap that can be generated (rendered) from data in the text file itself.

Once rendered the bitmap could then serve as a background elsewhere.

The downside of this is that it would result in unnecessary rendering of the same bitmap over and over each time the process is invoked resulting in wasted rendering cycles.

This is not insurmountable, especially if/where the bitmap would not be regenerated if the bitmap already existed locally. If present, the user would specify whether the bitmap was allowed to be updated/overwritten.

 

Constraints

How difficult would it be for most people to transition to such a bitmap-free workflow?

I assume this would not be a difficult workflow if the use of bitmaps were to be relegated to the latter part of the workflow (final lighting, texturing and surfacing).

 

 

*I use to know more about the embedded icon format within A:M files but have since forgotten the specifics. It doesn't sound quite correct to say they are base-32.

**As these embedded images are not optimal for large image size, a thought from many years ago was to use that to advantage by using the embedded image data as a proxy image that would be automatically replaced by the higher rez/external image should it be locally present. In absence of the local file the embedded 'icon' would be used and in absence of icon a default representation for that file type (or solid color) would be used. This being similar to A:M's current implementation of Library icons.

[robcat2075]

The only way to truly exclude bitmaps is to only use materials and surface properties for texturing.

 

Embedding images as text files is probably inefficient.

 

There have been times I wished that we could use vector graphic images natively. Those probably could be efficiently incorporated into A:M files.

 

What is the current situation that precipitates this desire a non-bitmap workflow?

[Rodney]

What is the current situation that precipitates this desire a non-bitmap workflow?

 

 

One use case:

Upload a single project file to the forum that contains everything needed to ensure success within that project file.

Avoid using zipped files, pdfs with attachments etc. as they introduce unnecessary variations into the process (often leading to missing or misplaced files).

 

On the simple side of this scale this is trivial but on the other with more complex projects this workflow breaks down largely because the average project relies on external files (primarily if not solely bitmap images).

[Clipping Path Specialists]

Buy using Bitmaps (Also Known as Raster Graphics)

[Rodney]

Buy using Bitmaps (Also Known as Raster Graphics)

 

I'm sorry, I don't follow you. I should use bitmaps in order to avoid using bitmaps?

 

Hmmm... on second thought, I may have to try that.