Learn how easy it is to sync an existing GitHub or Google Code repo to a SourceForge project! See Demo
Hallo Hans Martin,
Do you plan to implement the function glDrawTex*OES? I was obliged to use it now in my application and it make it not compatible with Vincent any more :=(
Is there a chance to see glDrawTex in future in Vincent?
I probably won't get to it myself any time soon, but if you need it, maybe you want to go ahead and provide a patch?
Shouldn't be too difficult: You need to add 4 state variables to the Texture class (and wire them into glTexParameter), and DrawTexOES can really be just a wrapper that internally draws a quad (2 triangles) calling into the Traingle Rasterization code.
I already tried to implement the glDrawTexOES in Blender with a quad mapped with a texture (to use Vincent) but it was awful :=(
But I will give a look! really! And I will probably come with other questions... for example, I have one:
Do I have to also update the "Runtime Code Generation"... do I have to deep understand also this part of the code?
Thanks for all your answers,
No, you don't need to understand the JIT part. You only have to set up RasterPos structures with initialized values for window coordinates, color, texture coordinates, fog. DrawTexOES still uses the regular fragment processing, so the regular triangle code would apply.
Oh, the only thing to do is to call into the Prepare... functions similar to the regular rendering calls to make such that the rasterizer is initialized correctly.
did you have any success?
I was very busy these last weeks to post a first working version of BlenderCE . Then I needed to solve "critical" problems to have a BlenderCE useable :=)
But I didn't forgot Vincent... I will not have access to my computer for two weeks, but as soon as I will be back, I will work on it. BlenderCE should now be useable without big big changes... waiting for rendering :=)
Sorry for this delay,
PS: I saw that the sources were updated... with also OpenGL ES 2! Will we have a next release soon :=) ??
Hey, no problem, just wanted to make sure you hadn't given up in the meantime...
Version 2: There is still a lot left to do, and I am not sure that it will ever work reasonably on a Pocket PC; so we'll see...
And the version 1? The downloadable version is from May. Do you plan to update it soon?
For the version 2, we will see :=) Did you tried BlenderCE? Vincent could bring a big advantage because it support SIP...
Yes, once I get back the results for the conformance submission, I will package another distribution. Hopefully, Vincent "IS" as conformant implementation by now.
PS: No, I haven't had a chance to try BlenderCE yet, I am usually using Maya.
I begin this Week end to work on Vincent to add the DrawTex fonctions to make it work with BlenderCE. I followed your suggestions and added in ContextRender a DrawtexxOES fonction making the following:
*filling a vertexpointer
*filling a texturepointer with the crop rectangle parameter specified in glTexparameteriv (I also needed to add this function)
The rectangle is drawn but without texture... I will check that better.
The vertex coordinates will be projected in screen coordinate but in the glDrawTex function, coordinates are already specified in screen one. Is there a way to desactivate the screen projection?
I also had a look in ContextTexture, and there are lot of functions copying pixels (like the one for readpixels) from a texture to texture, from surface to texture, etc... Don't you think it will be more efficient to implement glDrawpTex using one of this functions copying directly the current texture to the drawsurface? Maybe it will be faster? Do you see any problems in doing that? And if it is the best way, with copyPixels fonction to you advise to use?
Before you start coding, do you have the latest updates from CVS? The changes between 0.84 and the next release (hopefully this week) are HUGE.
ContextTexture: Well, the problem is that the rendering surface with it's split alpha plane is not a standard texture format, so you would need to create your own version of CopySurfacePixels, but in the opposite direction (e.g. the destination is the surface, not the source). Also, doesn't the DrawTexOES still perform all the fragment processing? None of that is happening in ContextTexture.
However, you might find the new triangle rasterizer a good starting point (which actually rasters rectangles, just clipped to a triangle!). Given the fact that everything is planar in your case, all the perspective coordinate transformation could go away, as well as all the C1/2/3 business.
I began with the old release because I was enable to compile the new one taken from CVS (evc4 project are not working). But yesterday, I compiled the CVS version using the old project file and making the following changes:
*I desactivated genscanline.cpp (some variable where not found)
*I undifined EGL_USE_GPP (because of problem with I32. Without EGL_USE_GPP, I32 is correctly defined)
*Select Automatic use of precompiled headers
Now the new version compilled good and my changes for glDrawTex begin to work. I can draw a rectangle with a texture using the glDrawpixel/glTexparameteriv methods. But the alpha test is not working. I will have a better look, it is probably caused by my wrong use of the alpha test.
For ContextTexture, you're right, glDrawpixel needs to perform all fragment processing.
Concerning EGL_USE_GPP, do you have an idea why I cannot compil when it is activated. I seems that the I32 type is not properly defined when gpp is used. Without GPP, it is ok.
Yes, there is something wrong with CVS - either the content on the server or the branch tags used by my local install; which is one of the reasons I want to switch to SVN: GenScanline.cpp is a good example: I deleted it quite some time ago, but it still shows up as a live text file -- but it's also in the attic, so, yes, I DID delete it.
GPP hasn't been supported for a long time (it was slower due to the function call overhead), and I started to remove all traces now.
Do you want to check the latest version of the project files? Also, any progress with the Alpha test?
So I don't need GPP anymore and no genscanline.cpp is needed. Good :=) I didn't check the project files again since saturday but I can give a try again and let you know.
For the alpha test, now it is ok, my test show the beautifull Blender fonts. The problem was comming from an approximation ... For my images, I have and alpha value like (GLubythe)255, if I write glAlphaFunc(GL_EQUAL, 1), the alpha test doesn't pass... but with glAlphaFunc(GL_GEQUAL, 0.999), it works :=) Probably something comming from Fixed point approximation.
I hoped to be able to compile BlenderCE with Vincent yesterday but I need now to solve strange include problems that I have with Vincent gl.h and NOT with Rasteroid gl.h. With Vincent includes, functions with *void as parameter in *.c files are not accepted by the compiler any more! I tried to compile BlenderCE with Rasteroid include and the Vincent library but BlenderCE was not so happy. I will check that better!
For the project, I managed to use the last ones (From CVS) just going in the CVS broaser and downloading the files… Something is going wrong during the checkout but the project files are ok!
After some time, I could compile BlenderCE with Vincent. There was a problem including the egl.h that uses the “window.h”. But changing my wrapper, it works now.
Ok, now the results with Blender. My first thinking was: “oh, it is not good :=(“. But looking that better, it is not good but maybe not dramatic.
The only differences for BlenderCE between Rasteroid and Vincent are the glDrawTex and glColor4ub functions.
In BlenderCE, elements drawn with glDrawpixel works but not all because I need to reset the projection and modelview matrix… but it doesn’t explain why BlenderCE has so many problems with Vincent, for example the 3D view is in some case drawn, in some other not drawn at all…
What could explain these problems is the way I wrapped glColor4ub. I will give a better look.
The last think that could explain such problems are the Fixed point approximations that I experimented with the alpha test.
I will also try with the old Vincent version to see what happen and maybe you could help me to better isolate the reasons of these problems.
A question: does Vincent anyhow separate the screen in two parts? In some windows, the top is ok, and down there are drawing problems.
Sorry for not being more precise but I will give a better look and if problems still are here, I could provide you some screenshots (better than big discussion).
>A question: does Vincent anyhow separate the screen in two parts? In some windows, the top is ok, and down there are drawing problems.
Maybe your coordinates or transformations are out of range for fixed point. AFAIK, Rasteroid is using floating point numbers.
FYI: I switched over to SVN as the primary repository for Vincent. There is info on the project homepage how to access SVN.
I understand. If it is really the problem, there will be few chance to run Blender with Vincent. You have in Vincent an arithmetic.h and .cpp where you define a new floating point class. Are you using it in Vincent right now? If the problem is comming from fixed point approximation, maybe your new float class could solve some problems.
I will spend more time on that as soon as it will be possible.
And Congratulation for your Conformance test success!