thegoodfellas/blogset-br huggingface dataset:
Este tutorial e meio que uma continuacao deste meu post sobre como colocar texto Latex no Inkscape. Como as vezes e preciso exibir modelos tridimensionais em alguns trabalhos, usar um software de edicao vetorial ajuda a colocar formatos com melhor resolucao em papers e slides. O Inkscape tem por padrao um renderizador vetorial que aceita modelos tridimensionais Wavefront ( .obj). Aqui eu vou mostrar como importa-los e edita-los (primeira parte) e como gerar arquivos de saida Encapsulated Post Script (.eps) e/ou Scalable Vector Graphics (.svg), formatos muito utilizados pra quem quer colocar figuras no Latex (segunda parte).Com o Inkscape aberto, va em Extensoes > Renderizar > 3D Polyhedron. Essa acao ira abrir uma caixa de dialogo em que voce poderar escolher que objetos voce quer renderizar. Escolha Load from file, informe o caminho completo do modelo (infelizmente nao tem um dialogo que cuide disso, entao e no braco mesmo que o modelo deve ser informado) e clique em Aplicar.Com isso voce ja renderizou seu modelo tridimensional. Voce pode alterar algumas caracteristicas do objeto que vai ser como por exemplo a posicao em que o modelo sera visualizado, na aba View. Nela voce podera definir 6 rotacoes a serem aplicadas no objeto em torno dos eixos X, Y e Z com os valores dos angulos em graus. Pode-se marcar a caixa Pre-Visualizar, para ver como sera exibido o objeto antes de renderiza-lo.E finalmente, pode-se definir o estilo do objeto a ser renderizado. Tem-se Scaling factor, para definir em que tamanho o objeto sera gerado; Fill color, com opcoes Red, Green e Blue para alterar os valores RGB das faces do modelo tridimensional; Stroke opacity e Stroke width para definir a opacidade e largura das arestas, respectivamente. Pode-se definir a posicao da luz em Light X, Y e Z, no caso do sombreamento do objeto ter sido habilitado na caixa Shading.Depois disso, se quiser inserir mais informacoes sobre o objeto, basta seguir o tutorial de insercao de Latex no Inkscape.Este e o fim da primeira parte. Para concluir, veja a segunda parte. Crumbs from eyal lebo on Vimeo. Rain from Christine Chen on Vimeo. Pollen from Jeremy Bondy on Vimeo. Lil' Boy Bunyan from Kyle Couture on Vimeo. Sick Leave from Jake Fried on Vimeo. Stitches from Reut Bortz on Vimeo. God Is Kidding - English Subs from Boaz Balachsan on Vimeo. A fox tale from A Fox Tale on Vimeo. Anna Blume from FinFilm on Vimeo. Hello there! Since we can add grains with physical properties, we can start to work on the hard part: particle selection, collision and animation. However, to do that, we need a way to make the objects created in a stroke to be persistent, since after the paintop is done all objects created during the operation are destroyed.To do that, we had to find a way to hold a collection of particles and then spread it after the pouring. Thus, I'm using Krita's Annotations, a feature that make possible to add aditional information to an image, like a comment, or, in my case, the collection of particles.With that,
we can save the image state after the creation/pouring of the grains and load them in a way that make it possible to start the usual painting operations. However, since the number of particles grows really fast, the pouring mode of the brush will just add the particles and save them in a collection that will be converted in an annotation. This annotation will be reloaded when the user start the spread mode, where we only modify the particles positions and don't add any new particle on the canvas.Another feature that we made these days is a private grid partition of the image. This is necessary since the number of particles grows really fast (in a common pouring painting we add from 5000 to 100000 grains), so to speed up particle selection and neighborhood detection, we are using two data structures that holds the particle indices associated with a grid and create a neighborhood relation between them, so we have to retrieve only those inside and near that grid cell.For instance, given a image, its associated grid is created by taking the canvas width and height and dividing each by the number of rows/columns disired. If the mouse is in the position (gx,gy), we will search the grid indexby taking its position, multiplying by the number of grids and dividing it by the image size:grid_x_position = number_of_horizontal_grids * gx / image_widthdoing the same for the grid vertical position. With that, we initialize a neighborhood relation structure where we will seach for particles to select and do collision, if need to be.We could search for these particles in the eight neighbors of the cell where the mouse is, but in practice we can reduce it by half, based on commutativity relation between neighbors. Suppose that (gx, gy) are not boundary cells. Them, since a particle i is neighbor of particle j, we only need to search for neighbors in one way only, in our case, the lower-right half of the neighborhood.Neighborhood search space restriction.Witha that, when the mouse moves, we can apply the forces on each particle based on the mouse speed and acceleration and after that, we animate them to have the dynamic feel. For now, the grid creation is based on the image size, but I'm doing the grid customization widget so the user can indicate the number of grids that suits his/hers needs better.Along with that, I have more few things to fix yet, but I'm enumerating them and soon we will have more details of the situation. Until next time!
Hello again!I've been fooling around with my granular particles repository these past days before do a real coding into Krita. I'm trying to optimize my simulation through a series of modifications in the code I wrote last week.My first attempt to run this granular particles simulation was quite a big failure, since it was really slow and full of errors. I correct some small things this past weekend and during this week I implemented a neighborhood restriction to the collision detection between particles.One of the reasons the code had a slow response was the fact that each particle was doing a collision detection with every other particle in the simulation. I initialized with 2010 particles, so we had a lot time wasted just doing useless calculations, since we only had to worry about each particle vicinity. So this time I implemented a grid so we could restrict the computation of collision only for neighbors particles. I have yet some other two improvements to test before generate some QImages: try the RK4 integrator instead of the Gear's predictor and corrector, and a more vectorizable grid construction which will be more easily implemented in a GPU.I'm already writting a more detailed post with all the theory used behind the scenes. But if you already took a look at the code before, this update will be easy to understand. Again, the code is well commented and any questions you can contact me here in the comments or sending me a message to my Gitorious account.See you all soon! :) Hi all!Today we have the final pencils down for the Google Summer of Code 2012. It was a wonderful experience do this work along with an awesome team such as the Krita developers. So much learning, and yet so much to be learned, that only a summertime it's not enough.Along the course of this project, I made some changes in many things, like the integrator, the particle implementation, mouse dynamics calculation and other features, which appeared while the job was advancing in its results. However, the initial functions related with the sand painting style were always the final purpose, so they endured. I described some of the implementations we made so far and what is yet to be done. I put a few links to past blog posts that described some of the features developed in more detail.What we haveThe problems concerning the Pouring operation was made in this post. There are some things to do, but for now, I believe that the current state will do. The Pouring set some properties related to the grains, such as size, mass and friction, which modifies the way the spread operation work The brush settings widget: we have the brush settings and the grains settings. Most of them have a diference in the Pouring operation mode.Once we add grains in the canvas, we can Spread them like a regular sand painting technique. Initially we had some numerical errors related with the grains positions and velocities. To fix this problem was really hard but we accomplish good results without
compromising performance.Some errors were due to mouse velocity calculation. In some situations, mostly when we move the mouse very fast, the time interval becames very small, close to zero, resulting in ugly results in the mouse velocity estimative. Fortunately, Krita already had some code with a solution for this, so I just had to understand what was done and adapt in my situation.I made a video of an experiment :Note that the particles are not erased while spreading. Taking a closer look we see that the particles are painted in new positions, although some of them act a little out of the expected behaviour.From the videos and images some of you could think that the brush works only in grayscale, but it does work in other color models :We made strokes of the Pouring operation with different colors in each one.After that, we did some Spread (the well defined white spaces) to show it working in the color grains. The main drawback in this Spread operation is the grain color handling. When we update the grains positions we repaint them using the current color (when putting a grain in a new position) and background color (when "erasing" the particle previous position). We can improve that by holding the color used in the Pouring operation inside the Particle class and deleting the previous position using a alpha channel painting. What is missing There are a few more things that were planed to be done, but I didn't have time to do it. Again, to the Spread operation work properly it took a very good effort so it could emulate the sand behaviour while the user painted using it.As explained in this post, we divided the canvas in a number of grid cells so it could apply the Spread only in those which are under the mouse position.However, the grains which are under the brush radius should have been spread as well. So one of the things to be done is the to extend the grid cell selection under the mouse radius, not only to the mouse position. There is also the posibility of customizing the grid size for user convenience: larger cells for faster computers, smaller cells for slower computers.A missing feature is the mouse "particle" customization. The spreading is made by emulating a particle in the mouse position with the same size as the brush radius. However, the mass and friction for the brush are the same as the current configuration of the grain particles, so it's not a very user friendly setting scheme, since the grains settings is only, obviously, for the grains.Another problem is when you save a document where you used the sand brush. When you load it, the particle positions are not retrieved, although we can use the created KisAnnotation to do so.And now?Well, now we wait for the evaluation. I tried to put a good documentation in the code so anyone can understand what is happening in each part of it. Although some things are missing, most of what was proposed was madeand the main features are
working well. I need to do some more tweaks to make the brush more user friendly, but for now, the visual results are satisfying.I really hope I can continue working in this brush in the next years so it can have a behaviour even more beffiting with the actual behaviour of sand painting. But we will make more plans when we are sure that everything went okay in the evaluation.Until next time!
Hi all! This week was a little rough, since I had some health issues, but nothing that could stop my coding. :)The simulation had a huge improvement when I changed the integrator. I was using the fifth order Gear's predictor and corrector integrator. Since most of the people in real-time applications says that the fourth order Runge Kutta integrator is the most effective, I implemented and saw what they where talking about: it's really fast! From a few minutes using Gear's algorithm with collision detection, it dropped to a few seconds with collision detection. A lot better. :)In the first time I was calculating the collisions between particles. To another improvement, I followed the hint given by Bugsbane in a comment of the last post and decided to remove the particles collisions.Indeed, for our purposes, these collisions must happen only in two specific situations: (1) when the mouse does the spreading of sand already in the canvas and (2) when one particle tries to pass the canvas boundaries.I had some numerical problems too, but that was my fault. In certain initial conditions, one of the particle properties was set to zero, without I even notice that. This propertie was the Young modulus, which gives us the elastic properties of a material. The value was set to zero, doing a unproper division in the equations and yielding numerical errors.When most of the previous errors and drawbacks was removed, I ploted the particles in a QWidget and animated it to see what was really happening:I took the particles properties from a initialization file (with it's positions, velocities, forces and other properties), instatiated them and draw each one with a drawEllipse method of a QPainter class. After that, for each time step, I applied the integrator and redraw the entire particle set on the canvas.I didn't pushed this part to the repository yet, but as soon as I finish the code comments and refactoring, it will be available. For now, I'm listing my next steps :- Forces evaluation : I will modify the normal force method to deal with a big "particle" of the size of the brush, so the particles can move properly in the canvas as the mouse emulates the artist finger. Another thing is that the code is working only with circular particles for now, so the tangencial force do not have any significant role for this simulation. Perhaps in the future when it starts to deal with non-circular elements it will be useful, but until there, it will remain unused.- Grid Mouse interaction: I divided the numerical simulation space in a grid to improve the performance. Now I will do the same with the canvas to detect which particles the mouse are touching and apply forces in each of them based on the mouse movements. I believe I will not have much problem with that when I port this code to a Krita paintop, since the canvas is already divided in 64x64 grid cells.- Canvas Boundaries: This will be more complicated since the behaviour of the sand in the boundaries depend
of the box material. Most of the particles have a little bounce back after colliding with the bounds, so I'm thinking if I set invisible particles at the bounds or if I set a default bounce back force for each particle.
Hi all! For the first time, I accomplished good performance improvement in a code after refactoring and commenting the code. This kind of practice really helps to clarify an implementation. My code was very "dirty", almost unreadable, so I rewrote all the comments, hoping that it could help anyone to understand what's going on in the scene. While rewriting, some major errors in the link cell algorithm was corrected. For instance, I had the grid cell operation retrieving the upper-right neighborhood of a cell, instead of the lower-right: this was driving me crazy.Anyway, most of the particles retrivement algorithm was slow due to unnecessary I/O operations in the annotations. So, to make things faster, one class is working as a particles manager (KisSandPaintOp), where it takes care of the interaction between the image properties and the particle architeture (grids, neighborhoods and the particles themselves).The KisSandPaintOp reads and writes all the particles from the annotation ans save them as the SandBrush add new particles.There are some other things that is missing, but is easy to be done:brush widget update: have to add the "mouse particle" settings, mostly the physical properties like mass, friction and dissipation. The grid customization had to be done again, since I removed while fixing the grid retrieve in the neighboorhood.brush default settings: the brush is begins with all its values set to zero, so I need to initialize them in a default valueThis was the good news of this week. Along with that, I made a list of the main flaws in the brush behaviour. I have some ideas how to fixing each one,but, like most of the previous ideas, I'm taking sometime to study the best ones:dynamic pouring fix: the mouse velocity and acceleration are taken as parameters to modify the added particles position. However, when the movement is in one direction only (X or Y) the grains form a line, yielding an undesirable result (see the picture below). I'm applying the mouse velocity and acceleration directly in the particle pixel position, and update them at each call of the paintAt() method of the SandBrush.Note the lines drawn in the X/Y directions. The mouse movement in this type of situation has to act in a more "random" way.sand depletion operation: the sand depletion (amount of sand for each brush stroke) is decreasing too fast. I need to find a more reasonable asymptotic function to do the depletion, with the brush radius as parameter. As bigger the radius is, more fast the sand should This is not a high priority feature, but it's nice to have a more real feeling of the painting.particle positions update in the spread operation: I implemented the main step of the spread operation (the final step of the brush function). As the following video shows, the correct grid position is retrieved allong with its particles to do the spread operation. However, for a reason I can't identify, the positions are not updated: I'm not deleting the previous positions yet, just trying to paint the new ones, which does not happen. And to make things
worse, the selected particles have their color modified to blue, something that I'm not doing.Anyway, just a few more steps and the spread operation will be done. The main properties of the brush is in this spread operation so accomplish the desired behaviour depends on this step. Fortunately, most of the necessary functions for this operations are working properly so I'm with good expectations of the results. Let's see how it will go!Till next time!
Ah, como e gostoso se apaixonar, querer dividir cada instante da sua vida e mostrar que nao ha segredos entre voce e a pessoa amada. Ah, que delicia saber que se pode confiar em alguem ao ponto de nao precisar usar mascaras. Feliz mesmo e quem encontra um relacionamento em que tudo isso acontece, nao? Nao!Confiar, amar, se entregar... E tudo muito lindo, mas limites precisam existir. Assim como uma planta nao vive sem ar, voce nao vive sem espaco. Voce precisa ter espaco para ser voce, lembrar do que e estar sozinho, nem que por alguns minutos, saber que algumas pequenas - ou grandes - coisas sao suas e de mais ninguem.Manter a individualidade e o desafio da maior parte dos casais. Ter um tempo para ficar sozinho, mesmo que seja para nao fazer nada. Dar uma volta no quarteirao e suspirar so porque o ceu esta lindo, sem ter ninguem perguntando o motivo. Para ser feliz e preciso respirar.E ai voce luta para ter uns momentos seus e divide a senha do seu e-mail e redes sociais com a lindona. Nao da, ne? E se voce quiser conversar com um amigo sobre a briga que teve com ela? E se seu amigo quiser te contar um segredo? Ele e seu melhor amigo, nao dela, lembre-se. E se sua mae achar que deve dividir apenas com voce algumas das coisas que pensa? Ela podera ler?Nao ter segredos e como asfixiar o amor. E nao sao segredos que fariam o outro mudar de ideia em relacao a voce, mas coisas que nao fariam diferenca na vida do outro. Coisas que sao suas e podem parecer extremamente importantes, mas so pra voce.Conversar, dar risada de besteiras, trocar informacoes com os amigos, ficar sabendo daquelas noticias inacreditaveis... Guardar textos que voce achou bacana, fotos que o faz sentir boas nostalgias, sejam de parentes, amigos e amigas, ex-namoradas (que sao apenas amigas hoje), criancas lindas, imagens de guerra ou de desastre... o que importa e que, por algum motivo, voce quis guardar. E tudo isso e so seu, voce nao precisa dividir.Manter um pouco do misterio faz bem a voce, a ela e ao relacionamento. Mas se voce acha que apenas isso nao o faria mudar de ideia, vamos para a parte tragica da coisa entao.Esse tipo de ideia sempre vem quando queremos provar a pessoa amada que realmentente a amamos, so que voce nunca podera saber que nao conhece tao bem a pessoa com quem esta se relacionando e tem apenas seu instinto de ultimo romantco, totalmente embriagado pela paixao, para confiar. Vale mesmo a pena colocar tudo em risco?Agora voce pergunta: "tudo o que?". Vamos la, a lindona pode ter uma crise de ciume e apagar todas as suas amigas e amigos das suas redes sociais, por exemplo. E se voce acha que eles sao seus amigos e vao entender, esta muito enganado. Seus amigos de verdade ficarao extremamente chateados com isso, afinal, eles vao estar sempre do seu lado, ja o seu amor nao se sabe ate quando.Ou entao, numa briga, ela
pode enviar mensagens no seu Facebook falando coisas horriveis, coisas que voce nunca diria, colocar fotos impensaveis que caberia somente a voces dois... Sao tantas as possibilidades de coisas mas que alguem pode fazer, que nao da nem pra escrever tudo aqui. Essas ai de cima sao apenas algumas das coisas que ja vi acontecer.E o pior de tudo isso e quando voce vira um monstro porque tem a senha dela em maos. Voce pode achar que isso nao vai acontecer, mas naquele dia em que voce acordar inseguro, se sentindo um lixo, a primeira coisa que vai fazer e entrar no e-mail dela e procurar. Procurar o que? Ninguem sabe, mas voce vai encontrar - nem que seja uma troca de mensagens com a mae dela, com um tom que voce nao gostou.Prova de confianca nao e dar acesso total a tudo que e seu, prova de confianca e nao dar esse acesso. Confiar e fechar os olhos e se deixar guiar, e acreditar no que nao se ve. Isso e confiar.Trocar as senhas e so se permitir ser controlado. E quando uma pessoa se descobre controladora, nem o ceu e o limiteMuito amor!!!Hugo.
tenho muita vida fluindo nas minhas veias e sendo desperdicada.Eu nao quero morrer, mas tambem nao gosto muito de viver...Antes de me apaixonar ja me preparo para deixa-la, eu morro de medo e e por isso que vivo fugindo.Antes de ter chegado, eu me vejo voltando.E eu preciso sentir o amor verdadeiro para toda a eternidade.Eu nunca me satisfaco, eu so quero sentir amor verdadeiro.Eu tenho muito amor fluindo em minhas veias e sendo desperdicado, pois ha um buraco na minha alma, da para ve-lo em meu rosto.Quero ir para um lugar imenso com voce, venha segurar minha mao!Eu quero contatar os vivos, nao sei se entendo bem este papel que me foi dado.Nao sei se entendo bem...Nao sei se entendo bem voce...Nao sei se me entendo bem...Nao sei se simplismete entendo...