Sorry your browser is not supported!

Hi Green Gandalf,

The way the point cloud works you can't just texture it like that. For one it's not a 3d object it has no polygons. That's the reason I am not using the simple texture object command. I have to use a more complex method.

Hi paul5147,

That is pretty neat. I get what you mean now. However, you zoom in the point sprites break apart the object and texture. My method can't have this breaking a part like this.

Wow, DarkVee! This looks strange! Btw, hi, DarkVee!

So why don't you use the point sprite/particle method suggested by others? I'm still baffled by what it is exactly that you're trying to do.

In fact if your cloud can't "break apart" why not use polygons?

Some sort of screenshot or image illustrating what you want would help everyone I'm sure.

Hi Green Gandalf,

I don't want to use the point sprite method using a shader. I want to make this work off the cpu. I have a very good reason for this.
Also when the time comes it I can break points up when I need to. First thing is get it working with texture on it. I then can do some other cool stuff with it.

Hi DevilsAdvocate I dunno who you are but what do think of this?

Yea, I like it!

I am pretty sure you can not do point sprites/cloud without using the shader approach in DBPro as the render method is changed deeper in the DirectX API than you can get with the DBPro wrapper.

Changing the rendering to "point" in a shader with the technique flags are possible though:
FILLMODE = point;
POINTSPRITEENABLE = true;
POINTSCALEENABLE = true;

And as you change the rendering to "point" any UV values are moot anyways as the vertexshader pass does not give you any UVs at all (only one vertex per render point). For instance, to be able to make atlas animated particles i had to make my own UVs in the PS.

As GG says you probably have to use the polygon (quad) approach or make your own dll to manipulate the rendering pipeline.

Regards

Impressive work, darkvee! And did you get that email I sent you?

That would be my preferred solution too - but unfortunately it seems that GFX cards tend to be rather picky about supporting this feature. For example, my oldish desktop (Vista + nVidia GeForce GTX 285 card) runs Dark Coder's old point sprite shader demo beautifully but the same demo just shows as blank on my newer laptop (W7 with some sort of combined Intel(R) HD Graphics 3000 + nVidia GeForce GT 630M cards). So I can see why darkvee might not want to go down that route. [Edit Dark Coder's demo runs beautifully on my wife's W7 laptop (nVidia GeForce GT 330M card). I'm going to have to steal it ... ]

My problem is that I still can't see what darkvee's trying to do exactly. For example, a cloud of points is just that - they occupy no area on the screen until you decide how many pixels each point will cover.

Typically, the cloud will have far fewer vertices than there are pixels in the corresponding screen area. For example, a region of 512x512 screen pixels will have 262144 pixels but the cloud might have only 36500 vertices. You have fill in the gaps somehow. An obvious way is to use a 512x512 texture so you can get a perfect match - but you still need to decide how to map pixels to the image. A more complicated way is to use the colours associated with the individual vertices - but that can only be a subset of the desired image pixels and, as others have suggested, you will need some sort of interpolation to fill in the gaps on screen. That will give you a blurred result even if the source image is 512x512.

I think darkvee needs to draw a diagram explaining how he wants image pixels, object vertices, and screen pixels to be associated with each other. Then we might be able to make progress.

Hi guys,

Yes that's one of the reasons I don't want to use shaders. The way I want this to work is I render the point cloud. At the points it starts the texturing. I then fill the area up and begin the draw call process. Instead of texturing the whole model 360 degrees it only textures what you see. I hope this explains the process I want.

I been studing directx for a day and a half so far. I think i'm about ready to make a directx c++ window of an object rendered.

Thanks DevilsAdvocate

Why not just purchase dark imposters? I'm sure that will solve your problem. If not to achieve what you want you'll have to understand how a model is processed and drawn to the screen as they've said above. I still recommend dark imposters that seems to be what you need.

Here's a link:
http://www.thegamecreators.com/?m=view_product&id=2293

I'm not sure but what I assume dark imposters does is create 3d plains for highpoly objects. It then uses an angle of error or something of the sort so that if the camera is turned soo far it will process a angle of the object so it seems 3dimensional and flawless. I have yet to use this but I assume it helps a lot with processing power.

If this is the only reason for doing this then this is definitely overkill. Especially when you consider that back face culling achieves this anyway. And that so far, what you've described would actually be far less efficient due to rendering an entire point cloud rather than just the outer surface.

I would assume this lack of actual geometry would also make it that little bit harder to achieve other effects such as normal mapping, reflections. Even transparency due to the ludicrous layers of vertices this would have to work with.

The other problem you'd have is that older graphics cards used the fixed function pipeline. This method, if ever made to work, will probably end up requiring a huge amount of vertices to get a resolution you'd be happy with so even though the graphics card's pixel processing would be fine, the vertex processing would become a bottleneck.

I'm really not trying to shoot down creativity here, but with stuff this tech heavy, if there was a better way to do it, it would be known about.

Didn't answer this earlier because I must have missed it.

Why didn't you at least try to get it working? Surely someone attempting such a delicate task is capable of changing this to this?

TheComet

Hi guys everyone have a Happy Halloween?



This shows you type code in and don't compile it. Always type stuff in and compile it. It is a bad habit to get into. When you do type & compile it looks professional. Not half-way code. Yes it was a easy an fix. However, if this was a large project I would of had to go through 1000's of lines of code to track it down. Now I put the code in. If it doesn't compile I throw it away. Simple as that.

Hi Andrew,

You say the vertex processing would become a bottleneck. Well the way I have everything planned out this won't happen. Everything will run just fine.

Well guys i'm getting closer. I'm working with directx. Hoepfully in about a week or two I can make a dll for dbp that does this. It will texture the point cloud the way I want it.

People on these forums are giving up their valuable time in order to help you out. There is no guarantee for bullet-proof code. The code I gave you was well thought through and had the smarts needed to complete the task at hand. Plus, when I got home from work, I did go back and fix it, so it was in fact a valuable contribution.

Although you make a point, I find the way you handle given help obnoxious. You have at least 5 code snippets in this thread, ranging from memblock examples to shaders, even to complete solutions to your problem, and you've rejected all of them and still won't tell us what you're trying to do other than saying "I have a very good reason".

I feel my time has been completely wasted here.

TheComet

I assure it has not been an complete waste. The samples everyone has showed will work but not on every pc. The GFX cards tend to be rather picky about supporting this feature.

You have to have code that works on any pc. We found a solution but it requires having to access directx. Only way to do this is in c++ code with directx. I do appreciate everyones help. Thank you so much for what you have done.

I like where this is going, DarkVee, keep up the good work! And also, check your email

@darkvee


There's a lot of talk about directX and C++ and so forth. But believe it or not, this kind of stuff was pulled off in QBASIC and AmigaBASIC in the past. Since computers are much faster now, and DarkBASIC Pro compiles to machine code (or a fast BYTE code - I'm not sure which) you could pull this off in DBPro. Like I mentioned early, Kevin Picone was doing this kind of thing in DarkBASIC Classic like 10 years ago. You'll have to wrap your brain around the concepts to understand it. The syntax (language) is just the syntax, but the methods and ideas are what you want to grasp.

I have an OK understanding of the 3D to 2D point process for mapping vertices. I also have a loose conceptual understanding of a 2D texture mapping across a "3D" surface.

Lets say you had a plane object with 4 vertices and it was square/flush with the screen/camera so you could see one entire side. The top left vertex had UVs of (0,0) and the bottom right had UVs of (1,1).

Let's also say you've already translated the 3D vertex coordinates to the 2D screen and the top two vertices were at (100,100) and (200,100). That's a span of 100 units across X.

Now, let's say your texture size is 256x256. That's 256 units across X. It's your task to find out how to map these 256 pixels across 100 pixels based on the UVs. Our UVs are easy in this case - it's 0 to 1 or 0 to 100% of the texture going straight across. The problem is finding out how you want to "squeeze" the 256 pixels into 100 pixels.

The first step is to find the start and end of our texture position based on the UVs.

StartX of texture = U1 * Texturesize X
StartX = 0 * 255
StartX = 0

Our end X based on our connected UVs straight across:

EndX of texture = U2 * Texturesize X
EndX = 1.0 * 255
EndX = 255

So far so good. Now, there are only 100 spots to fill with our texture so we'll have to pick the pixels we want:

pixelspacingX = 255.0/100.0

Based on how the UVs are connected by edges on a face, we find the same pixel spacing in the Y direction. Our face in this example is a simple square (quad). We always want the extremes of Xs and Ys for our face even if it is a triangle. That means we find the lowest U and V and the highest U and V and interpolate between those values in each direction (X and Y) to populate our face with the texture.

Our example is easy because it just so happens that the Y spacing is exactly the same as the X spacing.

To map the texture on our surface, we simple loop through the implied UVs for the whole surface:



The textureX and textureY values above are really just a variation of our pixelspacing that we calculated previously. It tells us which pixels we are going to choose from the texture because we can't pick them all. In our example, we could eliminate 2 divides and use the pixelspacing value if we wanted to speed things up a little.

The draw_texture_pixel function above would be code you implement to copy the pixel data from the image to the screen.

This is the basic concept of the process. You would have to adapt this for triangular faces and for edges that aren't aligned squarely to the camera. Also, you may include blending, dithering, and/or anti-aliasing to smooth out the pixels.

There are shortcuts like copying whole blocks of pixel data from the texture under certain circumstances instead of always mapping 1 texture pixel at a time.

You can also use the built in BITMAP and COPY bitmap functions in DBPro to help you out with the interpolation. There are a lot of possibilities but the first thing is to get a solid understanding of what you are trying to do.

EXCELLENT idea, @Latch!

@DarkVee, check your email! I wouldn't have to keep bugging you, if this forum had a PM system ><