I am trying to give a color to the points into a triangulation_3 on CGAL. I just take the example from CGAL describe here
I made a simple modification on this example to be able to draw the triangulation:
#include <CGAL/Exact_predicates_inexact_constructions_kernel.h>
#include <CGAL/Delaunay_triangulation_3.h>
#include <CGAL/Delaunay_triangulation_cell_base_3.h>
#include <CGAL/Triangulation_vertex_base_with_info_3.h>
#include <CGAL/IO/Color.h>
#include <CGAL/draw_triangulation_3.h>
typedef CGAL::Exact_predicates_inexact_constructions_kernel K;
typedef CGAL::Triangulation_vertex_base_with_info_3<CGAL::Color, K> Vb;
typedef CGAL::Delaunay_triangulation_cell_base_3<K> Cb;
typedef CGAL::Triangulation_data_structure_3<Vb, Cb> Tds;
typedef CGAL::Delaunay_triangulation_3<K, Tds> Delaunay;
typedef Delaunay::Point Point;
int main()
{
Delaunay T;
T.insert(Point(0,0,0));
T.insert(Point(1,0,0));
T.insert(Point(0,1,0));
T.insert(Point(0,0,1));
T.insert(Point(2,2,2));
T.insert(Point(-1,0,1));
// Set the color of finite vertices of degree 6 to red.
Delaunay::Finite_vertices_iterator vit;
for (Delaunay::Vertex_handle v : T.finite_vertex_handles())
if (T.degree(v) == 6)
v->info() = CGAL::Color(0,255,0);
CGAL::draw(T);
return 0;
}
But no matter which color I put on v->info() = CGAL::Color(0,255,0); the method draw always give the same red points in the window displayed:
I understand that the code is constructing a data structure that contains color information but this could be independent of the draw method, so i think that the window doesn't show me green points because this is not the way to color the points. If so, what is the way to get a triangulation with green points using the draw method?'.
In its current form, the viewer is not able to change the color of vertices nor edges.
But it is easy to change the code.
Copy the file draw_triangulation_3.h in your project
edit the method void compute_vertex(Vertex_const_handle vh), (line 92 in this file) to use the add_point method with a color as parameter: add_point(vh->point(), vh->info());
Related
I have used this website to create a shader that displays a snowman and some snowflakes:
http://glslsandbox.com/e#54840.8
In case the link doesn't work, heres the code:
#ifdef GL_ES
precision mediump float;
#endif
#extension GL_OES_standard_derivatives : enable
uniform float time;
uniform vec2 mouse;
uniform vec2 resolution;
uniform sampler2D backbuffer;
#define PI 3.14159265
vec2 p;
float bt;
float seed=0.1;
float rand(){
seed+=fract(sin(seed)*seed*1000.0)+.123;
return mod(seed,1.0);
}
//No I don't know why he loks so creepy
float thicc=.003;
vec3 color=vec3(1.);
vec3 border=vec3(.4);
void diff(float p){
if( (p)<thicc)
gl_FragColor.rgb=color;
}
void line(vec2 a, vec2 b){
vec2 q=p-a;
vec2 r=normalize(b-a);
if(dot(r,q)<0.){
diff(length(q));
return;
}
if(dot(r,q)>length(b-a)){
diff(length(p-b));
return;
}
vec2 rr=vec2(r.y,-r.x);
diff(abs(dot(rr,q)));
}
void circle(vec2 m,float r){
vec2 q=p-m;
vec3 c=color;
diff(length(q)-r);
color=border;
diff(abs(length(q)-r));
color=c;
}
void main() {
p=gl_FragCoord.xy/resolution.y;
bt=mod(time,4.*PI);
gl_FragColor.rgb=vec3(0.);
vec2 last;
//Body
circle(vec2(1.,.250),.230);
circle(vec2(1.,.520),.180);
circle(vec2(1.,.75),.13);
//Nose
color=vec3(1.,.4,.0);
line(vec2(1,.720),vec2(1.020,.740));
line(vec2(1,.720),vec2(.980,.740));
line(vec2(1,.720),vec2(.980,.740));
line(vec2(1.020,.740),vec2(.980,.740));
border=vec3(0);
color=vec3(1);
thicc=.006;
//Eyes
circle(vec2(.930,.800),.014);
circle(vec2(1.060,.800),.014);
color=vec3(.0);
thicc=0.;
//mouth
for(float x=0.;x<.1300;x+=.010)
circle(vec2(.930+x,.680+cos(x*40.0+.5)*.014),.005);
//buttons
for(float x=0.02;x<.450;x+=.070)
circle(vec2(1.000,.150+x),0.01);
color=vec3(0.9);
thicc=0.;
//snowflakes
for(int i=0;i<99;i++){
circle(vec2(rand()*2.0,mod(rand()-time,1.0)),0.01);
}
gl_FragColor.a=1.0;
}
The way it works is, that for each pixel on the screen, the shader checks for each elment (button, body, head, eyes mouth, carrot, snowflake) wheter it's inside an area, n which case it replaces the current color at that position with the current draw color.
So we have a complexity of O(pixels_width * pixels_height * elements), which leads to to the shader slowing down when too many snowflakes are own screen.
So now I was wondering, how can this code be optimized? I already thought about using bounding boxes or even a 3d Octree (I guess that would be a quadtree) to quickly discard elements that are outside a certain pixel (or fragments) area.
Does anyone have another idea how to optimize this shadercode? Keeping in mind that every shader execution is completely independant of all others and I can't use any overarching structure.
You would need to break up your screen into regions, "tiles" and compute the snowflakes per tile. Tiles would have the same number of snowflakes and share the same seed, so that one particle leaving the tile's boundary would have an identical particle entering the next tile, making it look seamless. The pattern might still appear depending on your settings, but you could consider adding an extra uniform transformation, potentially based on the final screen position.
On a side note, your method for drawing circles could be more efficient by removing all conditional branching (and look anti-aliased in the process) and could get rid of the square root generated by length().
My question is same as the following link
Drawing a line with a gradient color
I need to draw a curve with gradient color. Color should very from light blue to dark blue.I need to do it using VC++ and MFC. CPen class seems to provide only option of using LOGBRUSH. There are options to use various gradient brushes with closed shapes but not with lines or curves. I have plans to draw curve in small segments of lines with each segment of different shade thus forming a gradient. Is their any easier way?
You can do this with Gdi+
First you need to initialize Gdi+ See for example this link.
#include <Gdiplus.h>
using namespace Gdiplus;
...
struct GdiplusInit {
GdiplusInit() {
GdiplusStartupInput inp;
GdiplusStartupOutput outp;
GdiplusStartup(&token_, &inp, &outp);
}
~GdiplusInit() {
GdiplusShutdown(token_);
}
private:
ULONG_PTR token_;
} gdiplusInit; //This will initialize Gdi+ once, and shuts it down on exit
To duplicate the C# example in your question:
void CMyWnd::OnPaint()
{
CPaintDC dc(this);
Graphics gr(dc);
Point x = Point(0, 0);
Point y = Point(100, 100);
LinearGradientBrush brush(x, y, Color(255, 255, 255), Color(255, 0, 0));
Gdiplus::Pen pen(&brush, 2.0f);
gr.DrawLine(&pen, x, y);
}
How do I set where the columns show up in Susy?
I thought this would work:
#idLeftColumn{
#include span(1 at 1 first);
}
#idMiddleColumn{
#include span(1 at 2);
}
#idRightColumn{
#include span(1 at 3 last);
}
The html code has the order middle column, left column and then right column.
The website is showing the middle column first. This is the order in the source code.
Here is the full code: http://sassmeister.com/gist/60d85878921ca500c681
Susy uses standard float layout by default. Because floats stack up in the flow, you can't position them in any "absolute" way — you have to push or pull them from one position to another. Susy has no way of knowing their default position in the flow, but you can do it manually with the push() and pull() mixins.
Or you can use the isolation output option, which uses negative margins to pull everything flush left — and then allows you to position them in the way you are attempting above.
You can either do that inline:
#idLeftColumn{
#include span(1 at 1 isolate); // "at 1 first" is redundant
}
#idMiddleColumn{
#include span(1 at 2 isolate);
}
Or you can do it globally:
#include layout(isolate);
#idLeftColumn{
#include span(1 at 1); // "at 1 first" is redundant
}
#idMiddleColumn{
#include span(1 at 2);
}
I've got another question.
Here is my code:
#include <iostream>
#include <osg/Light>
#include <osg/LightSource>
#include <osg/PositionAttitudeTransform>
#include <osgDB/ReadFile>
#include <osgViewer/Viewer>
int main(int argc, char** argv)
{
osg::ref_ptr<osg::Node> loadedModel = osgDB::readNodeFile("cube.3ds"); //importing object
osg::ref_ptr<osg::StateSet> ss = loadedModel->getOrCreateStateSet();
osg::ref_ptr<osg::Image> image = osgDB::readImageFile("box_1.png"); //loading texture from file
osg::ref_ptr<osg::Texture2D> tex(new osg::Texture2D()); /creating texture for model from image
tex->setImage(image);
ss->setTextureAttributeAndModes(0, tex);
osg::ref_ptr<osg::TexGen> texGen(new osg::TexGen());
texGen->setPlane(osg::TexGen::S, osg::Plane(0.075, 0.0, 0.0, 0.5));
texGen->setPlane(osg::TexGen::T, osg::Plane(0.0, 0.035, 0.0, 0.3));
ss->setTextureAttributeAndModes(0, texGen);
osgViewer::Viewer viewer; //Creating viewer
viewer.setSceneData(loadedModel);
viewer.setUpViewOnSingleScreen(0);
return viewer.run();
}
So what this code is doing: It takes model from file (i.e. "cube.3s") and adding texture (image from file "box_1.png" to it. You can change texture on object by switching one image to another. But here is a question: He stretching image on whole model. How it can be done just by placing all image on each face of model (they are platonic solid (like pyramid, cube and etc.)).
This all boils down to the texture coordinates that were assigned to the model's vertices when it was built. If you convert cube.3ds to .OSG or .OSGT text format you can see the UV coordinates that the texture mapper uses to determine where in the texture map to look for each corner of each face. This is how textures are "pinned" to faces.
Just load and edit that cube or pyramid in a 3d modeling tool and fix up the UV coordinates to what you want.
Alternately, you could edit the .osgt file to change the UV coordinates assigned to each vertex.
I am using fltk 1.3.2.
I set the button's label color with
_button->labelcolor(fl_rgb_color(162, 60, 62));
but when I press the button, the color is changed.
I couldn't find the function how set the active label color.
Does anyone know how to do that?
Edit:
I use Fl::background() and Fl::foreground() functions before creating the window. This make the problem.
Edit2:
This example shows the problem.
#include <FL/Fl.H>
#include <FL/Fl_Window.H>
#include <FL/Fl_Button.H>
#include <iostream>
void HitMe(Fl_Widget* w)
{
std::cout << "Ouch" << std::endl;
}
int main(int argc, char ** argv)
{
Fl::background(0x60, 0x66, 0x60);
Fl_Window *window = new Fl_Window(320,130);
Fl_Button *b = new Fl_Button(10, 10, 130, 30, "A red label");
b->labelcolor(fl_rgb_color(162, 60, 20));
b->callback(HitMe);
window->end();
window->show(argc,argv);
return Fl::run();
}
When I commented out Fl::background() function everything is alright.
What you are seeing is the contrasting colour (see commented out code below). FLTK does this when the button is pressed. It gets the colour of the button, works out the contrasting colour based on the foreground and background colours. Have a look at the help for fl_contrast for more details.
Basically, if there is enough contrast, it will use the foreground colour otherwise it will find a contrasting colour for your background.
What can you do about it?
do nothing - that is how it is
choose a lighter background colour which will satisfy the contrast conditions
make your own button type with its own draw method
class KeepFGButton : public Fl_Button
{
public:
KeepFGButton(int x, int y, int w, int h, const char* s)
: Fl_Button(x, y, w, h, s)
{
}
void draw() {
if (type() == FL_HIDDEN_BUTTON) return;
Fl_Color col = value() ? selection_color() : color();
draw_box(value() ? (down_box() ? down_box() : fl_down(box())) : box(), col);
draw_backdrop();
// Remove the code that changes the contrast
//if (labeltype() == FL_NORMAL_LABEL && value()) {
// Fl_Color c = labelcolor();
// labelcolor(fl_contrast(c, col));
// draw_label();
// labelcolor(c);
//}
//else
draw_label();
if (Fl::focus() == this) draw_focus();
}
};
int main(int argc, char ** argv)
{
Fl::background(0x60, 0x66, 0x60);
Fl_Window *window = new Fl_Window(320, 130);
Fl_Button *b = new KeepFGButton(10, 10, 130, 30, "A red label");
...
Try the following and let me know if, when you run it, the label becomes white. If it doesn't then there is possibly something else that you are doing that is not quite right. If it does, I don't know what the problem is.
#include <FL/Fl.H>
#include <FL/Fl_Window.H>
#include <FL/Fl_Button.H>
#include <iostream>
void HitMe(Fl_Widget* w)
{
std::cout << "Ouch" << std::endl;
}
int main(int argc, char ** argv) {
Fl_Window *window = new Fl_Window(320,130);
Fl_Button *b = new Fl_Button(10, 10, 130, 30, "A red label");
b->labelcolor(fl_rgb_color(162, 60, 20));
b->callback(HitMe);
window->end();
window->show(argc,argv);
return Fl::run();
}
This is definitely too late to help the author, but in the event that this helps anyone else searching for an answer to this still relevant issue in FLTK, I'm going to offer my solution:
If you dig through the source code for FLTK 1.3.4-2 (current stable as of this post), there are a couple of built-in colormap indices which are referenced when the drawing of shadow boxes or frames are called: FL_DARK3 (for the boxes) and FL_DARK2 (for the scrollbar back color in Fl_Scroll). You can look at this FLTK documentation to see how to reset these colors to anything you wish at runtime. In particular, anticipating that this ugly red default mess will show up whenever there's a sufficiently dark background, it works well for me to just set these to a slightly lighter version of the overlayed box color:
Fl_Color boxColor = 0x88888800;
Fl_Color boxShadowColor = 0xaaaaaa00;
Fl::set_color(FL_DARK3, boxShadowColor);
Fl::set_color(FL_DARK2, boxShadowColor);
Now create your label as above and the display will be free of the red shadow. N.b. it is also possible to override the standard background2() behavior which resets FL_BACKGROUND_COLOR to the one produced by fl_contrast:
Fl::set_color(FL_BACKGROUND2_COLOR, yourBgColor);
The same trick works for other hard to reset colors like FL_INACTIVE_COLOR and FL_SELECTION_COLOR.
Hope this workaround helps.