Is it possible to alter a 3D object's core values? Say to alter the coords of a single 3D vertex? More importantly, for me, I would like to change the colour of a vertex of a 3D object (or at least to change the complete object to be a certain colour).
Main reason for me is I have some primitive 3D objects that are simply coloured with the X_OBJADDVERTEX command. At a later point I want to change that colour without using a different object or a different coloured texture. Another routine I have uses changing lighting to give a pulse effect on 3D objects, but because of problems with iOS it would be better if I could just change the core colour on the fly giving a similar effect.
Cheers
I wanted to do the same thing in my game.
I tried creating a shader that you pass a colour to, and it tints the object in that shade.
It worked great on the PC, just not for iOS (different OpenGL version? or something).
That was my next option too, just recreate the object (they are all created dynamically anyhow).
I think the 'X_GETFACE()' command gives you the vertex details of an object.
You could create a generic function that you pass on object id, and a colour.
It could strip the vertex info, and recreate the vertices with the new colour.
I don't know how slow that would be however!
Especially something you want changed per frame, like in a pulse effect.
Having an object with pre-made multiple frames where each is coloured as needed seems to be the least CPU-consuming possibility.
Hmm, probably. Although if it's only a single cube or plain then might not be that slow. Good point about frames. How do you go about inserting frames into a 3d object?
Cheers
At runtime? It's not possible yet :( but Gernot agreed that it will be implemented. :good:
What I meant is that .ddd objects created with the 3D Converter can have multiple keyframes, so that might be a way to do what you need.
I think that feature was recently requested (inserting frames into object).
Gernot says he added it to the 'to do' list!
http://www.glbasic.com/forum/index.php?topic=3843.msg57694#msg57694 (http://www.glbasic.com/forum/index.php?topic=3843.msg57694#msg57694)
[Edit] Oops, i was too slow!
Memory wise, or speed wise, or any other reason, are frames better than just an array of objects?
You could do 'frames' on your own by pre-generating a bunch of cubes (in this case) with different colours, each with an object id.
Add those ids to a list / array, then display the cube you want from that array list.
I thought of multiple objects but would be 255 for the colour cycle. Not great. Would be nice to duplicate object with a change to the colour.
Cheers
don't use colours - it's slow on mobile devices.
Use textures instead. If you want to swap colours, swap textures used. Might this work for you?
QuoteUse textures instead.
You could use the 'X_SETTEXTUREOFFSET()' command, along with a gradient texture.
(A texture with multiple colours, maybe each colour a pixel by a pixel, or larger if bleeding occurs)
IF your objects are simple solid colours, then the texture coordinates could all be set to pixel 1, 1. (or the first colour in the gradient) To change the object colour, just call X_SETTEXTUREOFFSET before drawing that object, and set the offset to the proper colour in your texture gradient.
This doesn't work of course if your objects aren't just a solid colour. You could still use X_SETTEXTUREOFFSET with a textured object, you'd just have to include all coloured versions of that texture in one texture.
Or, combine both a gradient and a regular texture, and assign multiple textures to an object, with the gradient being a colour overlay. I don't know how to do this in GLBasic, but two textures is possible in OpenGL I think. Then you still need to offset ONLY the colour overlay texture, if possible.
Hmm, now I have to rethink about abandoning my attempts at colour cycling! Shader approach had iOS issues.
nah. Just update the texture. (CREATESCREEN)
It's a simple 3d plain with a complicated texture not a simple one. I cycle the light colour so it gives it a cop car type effect. Unfortunately as was reported elsewhere on the forum iOS devices just don't look that good with lighting. I can get away with it but it's a lot more washed out (brightness or colour changes seemingly make no difference)
Because of the colour cycle I would need 256 textures to simulate the effect.
Cheers
Can you give an example program/video hint? I can't imagine what you try to do.
It should be pretty easy to do with updating the texture in my mind. I might have the wrong impression of what you try, though.
Quote from: Kitty Hello on 2011-Oct-18
nah. Just update the texture. (CREATESCREEN)
Is CREATESCREEN fast enough to use per frame?
So each frame, he could draw the texture to another screen via CREATESCREEN, using POLYVECTORS to set the current colour, then use that new sprite as the object's texture?
QuoteIs CREATESCREEN fast enough to use per frame?
I'd rather not. Another post earlier showed that a 60FPS app crawled to 30FPS on retina when createscreen was used for resolution scaling. I've only just got my app upto 60FPS at retina resolution and don't want to lose it again...
QuoteCan you give an example program/video hint? I can't imagine what you try to do
I can dig out the code later. And it works, just not in iOS 100% correctly (ie. the problem with the lights being washed out when used in iOS that we talked about before).
Essentially using 3ES just create a 3D textured cube (mine is a single faced plane to speed things up as much as possible but it makes no difference, and the texture itself isn't important) then create a light. The plane then obviously gets effected by the light. Then for each showscreen (or timer based I forget which) I simply cycle the lights colour. It basically cycles from 0 to 255 and back again, giving an impression of a pulsating light. Only on iOS the colours look washed out (as if brightness is too high but lowering it doesn't help as that washed out look is still there). Everything else (WebOS and PC) looks fine.
When creating the cube then if a colour is given to each vertex then the texture will be effected by that colour (like polyvector). So I thought an alternative solution would be to amend the vertex colour values for the object in question to use this colour cycling rather than using an actual light. It would also be nice in the future if I use 3D objects for the GUI (any news on the fix for 3ES for sticky 2D objects which didn't update to the correct 3D position on my project?) so the lighting doesn't effect them (unless you can turn off lighting on an object - can you? If so then I would go with that as it pretty much covers what I want).
Cheers
I'm pretty sure you can apply light only to certain objects, but I'm not sure how (or if GLBasic allows this).
I know when I created my custom shader, the light / fog wasn't applied to the affected objects by default.
I'd like to see a new 'X_' command that lets you specify a colour that is added / multiplied to the current vertex colours.
Gernot, I'm fairly new to this OpenGL stuff and how GLBasic works with it, does GLBasic have a set of default shaders it uses?
If so, you could create an alternate shader (or modify the default) to use this colour value to add to all the vertice colours, until told otherwise (by setting a '0' to the above 'X_' command or something).
This could be handy for special effects too! And you could target only specific models.
Or, does anybody know a custom shader to do the above that works on iOS?
(It'd be nice if it uses the lighting and fog specified by GLBasic too!)
For speed, could this be done only to the vertices, and not fragment/pixels? Or does it matter? This part confuses me!
In my fragment shader, the following line did the trick, but I think it didn't work on iOS or something:
(Does OpenGL 1.1 not allow fragment shaders? [Edit] If not, any plans on upgrading GLB to OpenGL ES 2.0?)
gl_FragColor = texture2D(TextureID1, gl_TexCoord[0].xy) + color;
If interested, here's my shaders I had before I gave up! (Is something in the following not valid on OpenGL 1.1 / iOS?)
// Vertice Shader
float FogEyeRadial(vec4 Rh) {
vec4 Re = Rh / Rh.w;
return length(Re);
}
void main(void) {
gl_FogFragCoord = FogEyeRadial(gl_ModelViewMatrix * gl_Vertex);
gl_Position = ftransform();
gl_TexCoord[0] = gl_MultiTexCoord0;
}
// Fragment Shader
uniform sampler2D TextureID1;
uniform float r;
uniform float g;
uniform float b;
void main (void)
{
vec4 color = vec4(r, g, b, 0.5);
gl_FragColor = texture2D(TextureID1, gl_TexCoord[0].xy) + color;
gl_FragColor = mix(gl_Fog.color, gl_FragColor, clamp((gl_Fog.end - gl_FogFragCoord) * gl_Fog.scale / 5.0, 0.1, 1.0));
}
If you want some Objects to not be affected by the lights, just draw them before the light. I did some Tests in the past, that showed that you can use multiple lights that only effect several objects, but ignore others (even works with toonshading, shadows,...). Its all about drawing order. ;)
QuoteIf you want some Objects to not be affected by the lights
That would work at a push although I use the 3ES plugin so would need to have a look at that. Bit cheeky Gernot but do you think you could have a look to add it as an attribute to 3ES like you did with the 2D sticky code? That still doesn't work for me BTW (the object moves so it obviously is trying to stick to the screen as a 2D object, but it doesn't move enough to work correctly and ends up moving off the screen).
More importantly though it would be good to fix the lighting problem with iOS (at least with 3ES if it's not a GLB problem as a whole). As I mentioned (with screenshots) in another thread it just looks washed out when lights are applied (while WebOS/Windows are fine). Changing brightness and colour does not have the required effect as it always looks washed out. Note the lighting does work as you can see effects on objects exactly like the other devices.
And finally yeah, the ability to change an objects vertex colour on the fly would be great. Individual vertexes would be great (I also have spheres that have no texture but alternative colours on each vertex), but to allow the whole object to change all it's vertexes to a different colour would be ideal.
Cheers
don't use CREATESCREEN, but USESCREEN for each loop. Yes, that's very fast.
Quotedon't use CREATESCREEN, but USESCREEN for each loop. Yes, that's very fast
You are losing me a bit there. How would you use this?
Any chance of the 3ES change to include a flag to exclude an object from lighting? Although I'd prefer another check on iOS lighting, or on the fly vertex re-colouring. Heh, sorry, I just pile it on :)
Cheers
This is very fast.
CREATESCREEN 3, 101, w, h
WHILE TRUE
USESCREEN 3
CLEARSCREEN
PRINT GETTIMERALL(), 0,0
USESCREEN -1
X_SETTEXTURE 101, -1
X_DRAWOBJ 1
SHOWSCREEN
WEND
In the end to keep my frame rate up I used a cycling alphamode value on the object in question (basically the background). It has a good effect of looking like the whole thing is pulsating (a siren goes off at the same time) which is what I was looking for. The other advantage is all the other objects stay the same so you can still navigate around perfectly fine. Good stuff.
Out of interest Gernot did you get a chance to look at the 2D sticky code for the 3ES system? You know the one you wrote about a month ago to keep a 3D object stuck at the same point on the screen? It never worked for me properly (object moves around but does not keep to the same point on the 2D screen) although my camera is constantly moving around quite a lot, rotating etc, so I don't know if that effect things. Would be great if could be sorted out though.
Cheers