[Zaxx]

Mark., on 25 July 2017 - 11:05 AM, said:

Whoever chose to use a 10K barrel was foolish. Just to verify I spent a few minutes making a very low poly ( 366 faces ) test barrel. I would imagine a very nice detailed version could be made with 1-2K. So when picking a model for conversion to voxel, or just making models to use, be realistic in the poly count.

Yep, this I agree with: 10K is a lot more than what an optimized model should be for a game like Blood and I'm sure that's why the fps tanks. Hell, even the bullet casings look a bit too detailed for the engine to pleasantly handle them at this state. Detail is nice but if it affects the performance this much no one will use additions like this.

[Kyanos]

Mark., on 25 July 2017 - 11:05 AM, said:

Whoever chose to use a 10K barrel was foolish. Just to verify I spent a few minutes making a very low poly ( 366 faces ) test barrel. I would imagine a very nice detailed version could be made with 1-2K. So when picking a model for conversion to voxel, or just making models to use, be realistic in the poly count.

The 10K poly model is actually from a voxel, at startup the engine runs a Ken S function in Polymost called vox2md3 or vox2poly... anyways that makes poly models out of voxels for OpenGL renderers, only software actually renders voxels. The only "fix" is to further optimize vox2poly (good luck) or make models to be used in place of voxels (that look like the original cubey voxel, but use less tris than the poly2vox output)

[Mark]

ok

[Kyanos]

From mdsprite.c in jfbuild/src

static voxmodel *vox2poly ()

Spoiler

static voxmodel *vox2poly ()
{
	int i, j, x, y, z, v, ov, oz = 0, cnt, sc, x0, y0, dx, dy, i0, i1, *bx0, *by0;
	void (*daquad)(int, int, int, int, int, int, int, int, int, int);
	coltype *pic;
	unsigned char *cptr, ch;

	gvox = (voxmodel *)malloc(sizeof(voxmodel)); if (!gvox) return(0);
	memset(gvox,0,sizeof(voxmodel));

		//x is largest dimension, y is 2nd largest dimension
	x = xsiz; y = ysiz; z = zsiz;
	if ((x < y) && (x < z)) x = z; else if (y < z) y = z;
	if (x < y) { z = x; x = y; y = z; }
	shcntp = x; i = x*y*sizeof(int);
	shcntmal = (int *)malloc(i); if (!shcntmal) { free(gvox); return(0); }
	memset(shcntmal,0,i); shcnt = &shcntmal[-shcntp-1];
	gmaxx = gmaxy = garea = 0;

	if (pow2m1[32] != -1) { for(i=0;i<32;i++) pow2m1[i] = (1<<i)-1; pow2m1[32] = -1; }
	for(i=0;i<7;i++) gvox->qfacind[i] = -1;

	i = ((max(ysiz,zsiz)+1)<<2);
	bx0 = (int *)malloc(i<<1); if (!bx0) { free(gvox); return(0); }
	by0 = (int *)(((intptr_t)bx0)+i);

	for(cnt=0;cnt<2;cnt++)
	{
		if (!cnt) daquad = cntquad;
			  else daquad = addquad;
		gvox->qcnt = 0;

		memset(by0,-1,(max(ysiz,zsiz)+1)<<2); v = 0;

		for(i=-1;i<=1;i+=2)
			for(y=0;y<ysiz;y++)
				for(x=0;x<=xsiz;x++)
					for(z=0;z<=zsiz;z++)
					{
						ov = v; v = (isolid(x,y,z) && (!isolid(x,y+i,z)));
						if ((by0[z] >= 0) && ((by0[z] != oz) || (v >= ov)))
							{ daquad(bx0[z],y,by0[z],x,y,by0[z],x,y,z,i>=0); by0[z] = -1; }
						if (v > ov) oz = z; else if ((v < ov) && (by0[z] != oz)) { bx0[z] = x; by0[z] = oz; }
					}

		for(i=-1;i<=1;i+=2)
			for(z=0;z<zsiz;z++)
				for(x=0;x<=xsiz;x++)
					for(y=0;y<=ysiz;y++)
					{
						ov = v; v = (isolid(x,y,z) && (!isolid(x,y,z-i)));
						if ((by0[y] >= 0) && ((by0[y] != oz) || (v >= ov)))
							{ daquad(bx0[y],by0[y],z,x,by0[y],z,x,y,z,(i>=0)+2); by0[y] = -1; }
						if (v > ov) oz = y; else if ((v < ov) && (by0[y] != oz)) { bx0[y] = x; by0[y] = oz; }
					}

		for(i=-1;i<=1;i+=2)
			for(x=0;x<xsiz;x++)
				for(y=0;y<=ysiz;y++)
					for(z=0;z<=zsiz;z++)
					{
						ov = v; v = (isolid(x,y,z) && (!isolid(x-i,y,z)));
						if ((by0[z] >= 0) && ((by0[z] != oz) || (v >= ov)))
							{ daquad(x,bx0[z],by0[z],x,y,by0[z],x,y,z,(i>=0)+4); by0[z] = -1; }
						if (v > ov) oz = z; else if ((v < ov) && (by0[z] != oz)) { bx0[z] = y; by0[z] = oz; }
					}

		if (!cnt)
		{
			shp = (spoint2d *)malloc(gvox->qcnt*sizeof(spoint2d));
			if (!shp) { free(bx0); free(gvox); return(0); }

			sc = 0;
			for(y=gmaxy;y;y--)
				for(x=gmaxx;x>=y;x--)
				{
					i = shcnt[y*shcntp+x]; shcnt[y*shcntp+x] = sc; //shcnt changes from counter to head index
					for(;i>0;i--) { shp[sc].x = x; shp[sc].y = y; sc++; }
				}

			for(gvox->mytexx=32;gvox->mytexx<(gmaxx+(VOXBORDWIDTH<<1));gvox->
mytexx<<=1);
			for(gvox->mytexy=32;gvox->mytexy<(gmaxy+(VOXBORDWIDTH<<1));gvox->
mytexy<<=1);
			while (gvox->mytexx*gvox->mytexy*8 < garea*9) //This should be sufficient to fit most skins...
			{
skindidntfit:;
				if (gvox->mytexx <= gvox->mytexy) gvox->mytexx <<= 1; else gvox->mytexy <<= 1;
			}
			mytexo5 = (gvox->mytexx>>5);

			i = (((gvox->mytexx*gvox->mytexy+31)>>5)<<2);
			zbit = (int *)malloc(i); if (!zbit) { free(bx0); free(gvox); free(shp); return(0); }
			memset(zbit,0,i);

			v = gvox->mytexx*gvox->mytexy;
			for(z=0;z<sc;z++)
			{
				dx = shp[z].x+(VOXBORDWIDTH<<1); dy = shp[z].y+(VOXBORDWIDTH<<1); i = v;
				do
				{
#if (VOXUSECHAR != 0)
					x0 = (((rand()&32767)*(min(gvox->mytexx,255)-dx))>>15);
					y0 = (((rand()&32767)*(min(gvox->mytexy,255)-dy))>>15);
#else
					x0 = (((rand()&32767)*(gvox->mytexx+1-dx))>>15);
					y0 = (((rand()&32767)*(gvox->mytexy+1-dy))>>15);
#endif
					i--;
					if (i < 0) //Time-out! Very slow if this happens... but at least it still works :thumbsup:
					{
						free(zbit);

							//Re-generate shp[].x/y (box sizes) from shcnt (now head indices) for next pass :/
						j = 0;
						for(y=gmaxy;y;y--)
							for(x=gmaxx;x>=y;x--)
							{
								i = shcnt[y*shcntp+x];
								for(;j<i;j++) { shp[j].x = x0; shp[j].y = y0; }
								x0 = x; y0 = y;
							}
						for(;j<sc;j++) { shp[j].x = x0; shp[j].y = y0; }

						goto skindidntfit;
					}
				} while (!isrectfree(x0,y0,dx,dy));
				while ((y0) && (isrectfree(x0,y0-1,dx,1))) y0--;
				while ((x0) && (isrectfree(x0-1,y0,1,dy))) x0--;
				setrect(x0,y0,dx,dy);
				shp[z].x = x0; shp[z].y = y0; //Overwrite size with top-left location
			}

			gvox->quad = (voxrect_t *)malloc(gvox->qcnt*sizeof(voxrect_t));
			if (!gvox->quad) { free(zbit); free(shp); free(bx0); free(gvox); return(0); }

			gvox->mytex = (int *)malloc(gvox->mytexx*gvox->mytexy*sizeof(int));
			if (!gvox->mytex) { free(gvox->quad); free(zbit); free(shp); free(bx0); free(gvox); return(0); }
		}
	}
	free(shp); free(zbit); free(bx0);
	return(gvox);
}

[kimec]

Drek, on 25 July 2017 - 12:17 PM, said:

The 10K poly model is actually from a voxel, at startup the engine runs a Ken S function in Polymost called vox2md3 or vox2poly... anyways that makes poly models out of voxels for OpenGL renderers, only software actually renders voxels. The only "fix" is to further optimize vox2poly (good luck) or make models to be used in place of voxels (that look like the original cubey voxel, but use less tris than the poly2vox output)

The only open question is the methodology of remodeling Blood's voxel objects. Should the new models retain "cubey voxel" design or can they be smoothened out? I, for one, would go for the cubey voxel design.
Another question is whether the tool used to create the new voxel models supports export to Blender or something similar. Was it fgsfds creating those? Was it MagicaVoxel he mentioned as the number one tool? Yep, it does support export to OBJ mesh.

 magica.jpg (45.79K)
Number of downloads: 39

So to recap, we would need:

MagicaVoxel: open source, free of charge
Blender: open source, free of charge
Volunteers: ?

[fgsfds]

Mark., on 25 July 2017 - 11:05 AM, said:

Just to verify I spent a few minutes making a very low poly ( 366 faces ) test barrel. I would imagine a very nice detailed version could be made with 1-2K.

Except it looks like a polygonal, not voxel model.
I'm not making 10k polygon models because I want to (for that matter, I'm not making poly models at all). I'm making KVX voxel models that are later converted to md2 models by the engine. And them having 10k polygons is just how voxels work.

kimec, on 25 July 2017 - 02:09 PM, said:

Should the new models retain "cubey voxel" design or can they be smoothened out?

Voxel models are "cubey" by definition.

[m210®]

Quote

From mdsprite.c in jfbuild/src

When I said about 10k polygons, I mean vox2poly making it...without this method voxel will be 50k polygons.

[kimec]

fgsfds, on 25 July 2017 - 06:12 PM, said:

Voxel models are "cubey" by definition.

Actually, I would argue that voxel models are made of points by definition.

Anyhow, what I meant is that if we choose to create MD3 replacements for each and every model, we should still design the models to look as if they were created by vox2poly (with pixelated texture), which means not using smooth curves but intentionally make them look cubey. Does that make sense?

The source model data would still be from MagicaVoxel, but there would be a manual postprocessing step in Blender where we would reduce polycount and map textures, etc. Result of the postprocessing would be MD3. However, maybe curved models like barrel need to be handled a bit differently.

[fgsfds]

Quote

Actually, I would argue that voxel models are made of points by definition

Not sure what you mean.

I had a similar idea. I'm not sure that the resulting model optimized by hand will be any better than the optimizations the engine already does, but it worth a try.

[Devon]

fgsfds, on 25 July 2017 - 11:46 PM, said:

Not sure what you mean.

I had a similar idea. I'm not sure that the resulting model optimized by hand will be any better than the optimizations the engine already does, but it worth a try.

Yeah it would suck if someone did loads of work and it was not needed in the end because the engine gets optimized.

I mean the engine is far from finished i guess and any potential work being made so early might be unneeded in the end as maybe the voxels will work well enough later on ?

[fgsfds]

M210 is currently working on optimizing voxels rendering. I wouldn't do anything until it's finished. I might not be even necessary to do anything after that.

[kimec]

fgsfds, on 25 July 2017 - 11:46 PM, said:

Not sure what you mean.

Voxels are simply points with spatial information and color.
The BUILD's software renderer uses some kind of direct volume rendering. Obviously, the engine did not convert individual voxels into cubes made of polygons back in 1996. If it would, it would have ended up with 10k barrel in 1996 just as we do now.
So when Ken S wrote the newer Polymost, instead of solving the problem of how to do direct volume rendering on the GPU, chose to do polygon extraction from voxels (vox2poly), that is to convert the volume represented by voxels into small cubes made of triangles. Most likely direct volume rendering wasn't even considered an option with consumer grade GPUs back then (and it hardly is nowadays).

Therefore no matter what optimisation Alex will do for the engine, it will not change the fact that vox2poly will always extract some 10k polygonal mesh from the barrel.
The only way to extract less than 10k tris from the barrel is to implement or use different algorithm in vox2poly.
Or to make the model your self -> human based polygon extraction.

[Mark]

I guess there is still something I don't understand that probably relates to the fact that I have no idea how you make a voxel item.
The barrel for instance. Does it have to be created by placing a boatload of discs on top of one another to build up it's height? If so, that explains the high face count when converted. Especially if hidden faces are not removed. If its not a bunch of thin slices piled up I can't see why a barrel voxel would get transposed to 10K faces. What am I missing?

[icecoldduke]

kimec, on 26 July 2017 - 04:10 AM, said:

Therefore no matter what optimisation Alex will do for the engine, it will not change the fact that vox2poly will always extract some 10k polygonal mesh from the barrel.

That is so beyond wrong its insane. There are plenty of things that can be done to optimize that function. Furthermore there are plenty of things that can be done to optimize voxel rendering in build.

[Striker]

One possible method of optimizing voxel rendering in OpenGL, is to draw voxels using an array of points drawn back-to-front, instead of converting to models. Visually, this would look like voxels in software rendering. Not sure just how much faster that would be however.

[Mark]

I may be wrong but my perception is that the people that want voxels are the same people that play in software mode only. Is there even a "market" for voxels outside of software rendering that makes it worth the effort to implement?

[Kyanos]

Mark., on 26 July 2017 - 08:14 AM, said:

I guess there is still something I don't understand that probably relates to the fact that I have no idea how you make a voxel item.
The barrel for instance. Does it have to be created by placing a boatload of discs on top of one another to build up it's height? If so, that explains the high face count when converted. Especially if hidden faces are not removed. If its not a bunch of thin slices piled up I can't see why a barrel voxel would get transposed to 10K faces. What am I missing?

The pixels are two triangles each. Simple uv maps and skins will cut a ton of faces from flat surfaces, but it's a shit ton of work, I've started doing it for the barrel. Can generate othoganal pics in magicavoxel then pick apart the .obj to cull unneeded faces and do a proper-er skinning.

As for the market, it's original game content that comes with Blood and SW, some may call it baggage...

[kimec]

icecoldduke, on 26 July 2017 - 08:17 AM, said:

That is so beyond wrong its insane. There are plenty of things that can be done to optimize that function. Furthermore there are plenty of things that can be done to optimize voxel rendering in build.

Sorry, I've tried hard but I simply cannot react to your comment in a technical and objective way. So let's do an experiment instead:

Load the barrel voxel model into your PolymerNG and report back the generated polycount and attach a screenshot of the generated wireframe model from the game. Just as Alex did. Easy-peasy.

PS1: I've diffed JFDuke vox2poly implementation vs your vox2poly implementation in PolymerNG. Do you think I've found some optimization not present in the original implementation?
PS2: What voxel rendering? Unless you are using the software renderer, there are only meshes made of triangles to be rendered.

[Mark]

I'm all for voxels for software renderer but I'm questioning if support for Polymost is even necessary considering the possibility few people that would make use of them.

[kimec]

Mark., on 26 July 2017 - 09:57 AM, said:

I may be wrong but my perception is that the people that want voxels are the same people that play in software mode only. Is there even a "market" for voxels outside of software rendering that makes it worth the effort to implement?

Rumour has it, that the market is being created as we speak. It should be VR and supposedly normal maps just don't have the right kick anymore when you're looking at them in 3D.

But this is all based on a controversial claim from a controversial Australian company Euclideon who have a controversial history.

[Mark]

I suppose I should have clarified by saying the Eduke32 market, not just market meaning in general. My mistake.

[Kyanos]

Striker, on 26 July 2017 - 09:16 AM, said:

One possible method of optimizing voxel rendering in OpenGL, is to draw voxels using an array of points drawn back-to-front, instead of converting to models. Visually, this would look like voxels in software rendering. Not sure just how much faster that would be however.

You would be drawing a single plane per voxel? Maybe it could be optimized to do some type of culling too.

kimec, on 26 July 2017 - 11:54 AM, said:

Rumour has it, that the market is being created as we speak. It should be VR and supposedly normal maps just don't have the right kick anymore when you're looking at them in 3D.

But this is all based on a controversial claim from a controversial Australian company Euclideon who have a controversial history.

Voxels are still ahead of their time. Hardware is not made "voxel friendly" either, a change is due.

[Kyanos]

Drek, on 26 July 2017 - 12:06 PM, said:

Maybe it could be optimized to do some type of culling too.

Ha, just looked up that euclideon company, they do voxel culling in their "unlimited detail" 3d "cloud point" (voxels) engine.

wiki said:

Unlimited Detail is described by Euclideon as a form of point cloud Search engine indexing system, which uses a large number of individual points to create models, instead of a more traditional polygon mesh. According to their description, the engine uses a search algorithm to determine which of these points are visible on-screen, and then displays only these points. On a 1024 × 768 display, for example, the engine would display only 786,432 visible points in each frame. As the engine is displaying the same number of points in every frame, the level of geometric detail provided is limited only by the amount of hard-drive space needed to store the point cloud data, and the rendering speed is limited only by the screen resolution.Euclideon have previously described their technique as being a voxel rasterizer,[6] but decided to use their own terminology such as "3D atoms" and "point cloud", saying that "that word [voxels] doesn't have the prestige in the games industry that it enjoys in medicine and the sciences".

[kimec]

Mark., on 26 July 2017 - 12:05 PM, said:

I suppose I should have clarified by saying the Eduke32 market, not just market meaning in general. My mistake.

Me being dumb.

[kimec]

Drek, on 26 July 2017 - 12:06 PM, said:

Voxels are still ahead of their time. Hardware is not made "voxel friendly" either, a change is due.

If you haven't yet, just check out what this guy is doing. That is 2 years ago. The youtube channel is also a must watch. First time I saw that was like WTF, is this even real?

[icecoldduke]

kimec, on 26 July 2017 - 11:42 AM, said:

PS1: I've diffed JFDuke vox2poly implementation vs your vox2poly implementation in PolymerNG. Do you think I've found some optimization not present in the original implementation?
PS2: What voxel rendering? Unless you are using the software renderer, there are only meshes made of triangles to be rendered.

PS1: I never made changes to vox2poly. I've anaylized vox2poly before and there is room for improvement. I don't have my notes in front of me, but there is room for optimization.

PS2: When I was working on PolmyerNG I created a screen space voxel pass. I didn't have to use any tris. It didn't work for my purposes at the time because I wanted realtime shadows on the assets.

[Hendricks266]

kimec, on 26 July 2017 - 11:54 AM, said:

Rumour has it, that the market is being created as we speak. It should be VR and supposedly normal maps just don't have the right kick anymore when you're looking at them in 3D.

But this is all based on a controversial claim from a controversial Australian company Euclideon who have a controversial history.

I knew I recognized that name and Mark's post confirmed it. How many years of puffery and exaggerated noob-bait claims has it been without any results?

I am partly skeptical of the normal map claim. If the scene is properly rendered twice, once for each eye, there should be at least some effect, though for sure they will never be able to do anything with shape outlines. Even then, the 3D illusion should not be broken or anything like that.

But, this is getting off-topic.

[icecoldduke]

kimec, on 26 July 2017 - 11:54 AM, said:

But this is all based on a controversial claim from a controversial Australian company Euclideon who have a controversial history.

You should not be citing them as a reference for anything. All they do is make bullshit, unfounded claims.

[kimec]

icecoldduke, on 26 July 2017 - 12:26 PM, said:

PS1: I never made changes to vox2poly. I've anaylized vox2poly before and there is room for improvement. I don't have my notes in front of me, but there is room for optimization.

PS2: When I was working on PolmyerNG I created a screen space voxel pass. I didn't have to use any tris. It didn't work for my purposes at the time because I wanted realtime shadows on the assets.

So by -1 karma point you've actually meant, the barrel would translate to 10 K. That is enough to know.

PS1: Good for you.
PS2: Good for you. Also, well done!

[kimec]

Hendricks266, on 26 July 2017 - 12:29 PM, said:

I knew I recognized that name and Mark's post confirmed it. How many years of puffery and exaggerated noob-bait claims has it been without any results?

I am partly skeptical of the normal map claim. If the scene is properly rendered twice, once for each eye, there should be at least some effect, though for sure they will never be able to do anything with shape outlines. Even then, the 3D illusion should not be broken or anything like that.

But, this is getting off-topic.

Six or seven. Yes, the snake oil...